Paid Support?

#1 I think this is a GREAT idea, and would definately be willing to pay a fee to have access to faster/more specialized support.

I have been learning this engine for a year now. I find most of my time is spent searching and deciphering obscure examples of how someone else did something and then trying to apply it to my project just to move forward. In the process I learn nothing about why is was done that way and how it really works.

I would much rather ask questions and get responses back with specifics of how it relates to my project.

Kevin

#2 Saw your other topic on this, but didn't have time to post. I don't really have time now but I'm avoiding homework.

I think it is extremely underpriced for the level of access noted. Perhaps a per-incident fee like a large number of software vendors inside and outside the game industry. Also, another area which would be extremely difficult to navigate would be whether it would provide engine support (who is DMoore and where can I get ahold of him to smack for map2dif?) or if it extends to game support for features and algorithms that have been incorporated. Also, for some things like, for example, integrating PhysX into TGE, it may seem deceptively simple after compiling in the resource but then expanding it to all game objects and utilizing all of the features that PhysX provides in all contexts becomes a major sticking point that could easily take the $50 per month into a realm where the developers trying out end up with several hours of dev time oriented towards a single instance which doesn't relate to direct engine enhancements that could help everyone but only direct game enhancements that only helps that developer.

And so the engine/QA/documentation teams get spread even thinner. Or else the price of the engine rises to accommodate a line of support staff of programmers and artists; which could easily lead to price-per-incident scheme.

Support methods are important, but it is very difficult to assess game-level versus engine-level support and explain it. You can look through the topics from each week (I do) and see where people expect features that are unique to their genre or gametype as universals in the engine. Why? Well, because they don't want to have to do work to include something so "simple"--which is used often but more accurately translates to "a feature mostly universal to my type of game and therefore should be an integral part of the engine".

I see the problem on a number of levels. The first is that GG (rightly, IMO) included starter kit examples. The problem with including these, which is a problem with any engine that includes examples that are not solely from the community (though it often extends to the community regardless) is that support to extend the examples is often assumed. I see questions on the support forums for Unity on the platformer tutorial or on C4 about the FPS example or on BeyondVirtual about each example, etc. Even the GameMaker community is constantly asking questions that are specific to their games but using the example tutorials as agents for their entitlement to support. Some communities deal with this sense of support entitlement differently (some ignore it/others patiently answer it/still others are caustic/etc).

Support is a nebulous entity. Everyone has their own ideas of what support entails, and often arguments errupt over these interpretations. I've seen it here (even though the support base are the forums or alternatively BootCamps if the organization can afford it) and at other sites (from Adobe to NewTek to GameMaker to Irrlict. Even free engines, often which have huge disclaimers about support, are subject to this problem of what constitutes an engine bug or what constitutes a support issue about my game. Perhaps if there were a categorical establishment for types of developers, it might be a clearer issue (talk to the right person) except that categories break down or disappear on the even more nebulous "indie" level of development. The term itself implies a wide spectrum of dreamers, hobbyists, professionals that are moving from the traditional industry to make the games they wanted to make, and numerous others. Often there are people who do not know, for example, C++ or have any programming experience so they are dealing with multiple hurdles (learning the engine, learning C++, learning TorqueScript, learning an IDE or two if they are looking with excitement at cross-platform development, etc). I see questions about basic C++ all the time. It is easy to say "we don't teach programming concepts and languages" but that gets lost in translation as "Support told me that they don't want to help me."

There are a lot more instances, but I have 13 more pages to write on my 25 page paper for Theory, so I'm going to get back.

I think it would be a good idea, rather than a price scheme like mentioned (unless it were third-party support, which would be an interesting idea as well) to discuss support options, support limitations, and common sticking points. I would be extremely interested in such a discussion. The scheme as presented seems wholly out of proportion for the number of questions that people can ask in a month versus what their expectations of support could be.

#3 Thank you both for the great input!

The reasoning behind a monthly support option is similar to something like hosting...or Pre-Paid legal..structure. Which offer unlimited support but really have a large amount of subscribers to cover costs..so in essense is shared by all clients.. I thought that would be ideal for Indie developers.

But I definitely see the incident point..and since programming and art issues do require much more support for a single request...I am looking at using that structure instead

Here is a rework of the support structure based on your input:

Detailed Coverage/Restrictions:

Core Technologies Only: TGE, TGEA, RTS, TGB (no third party code or integrations, libraries, content packs.)
Specific to: C/C++, Torque Scripting, GUI, Internal Art Usage some importation assistance (will keep the domains specific)
Game logic advice, Level creation advice, How to advice, explanations, workarounds or possible solutions.

My company (external to GG) may choose to accept or deny a request for support depending on the request. If we deny a request there is no charge of course..If its in the listed domains we would most likely accept it..

Also the reasoning behind doing this is like you said Kevin, that it is and was for me painfully slow in learning the major features of Torque via forums and trying to get help from GG. And would have gladly paid for quick support on an incident or monthly payment.

DRAFT

-- Option 1 (Premium Indie Support level)--
Pricing:
Per Incident/request - $25.00

Features (Per Incident):
Direct Email support (as much as deemed necessary)
Includes advice, workarounds, solutions, or descriptions or possible fixes
Review of up to 2 pages of code or process or issue description
Guaranteed assistance
Professional help
Response within 24 hours

-- Option 2 (Commercial Support level)--
Pricing:
Per Incident/request - $100.00

Features (Per Incident):
Phone support
Direct Email support (as much as deemed necessary)
Includes advice, workarounds, solutions, or descriptions or possible fixes
Review of up to 5 pages of code or process or issue description
Guaranteed assistance
Professional help
Response within 24 hours

Optional Production Services (which an incident can be escalated to a project):
Feature / Module Code Request (negotiated)
Content Pack Request (negotiated)
Fix or process (negotiated)

Other arrangements may be made like purchase of a 5, 10, 20 incident pack for reduced rates up front.

I think the great thing about this arrangement is that it would allow a dedicated support staff to be added to even an Indie or commercial level project/team as needed. And still be affordable and worthwhile for both Indies/commercial and our side..

Also I think the benefits would be extreme, especially if it helps teams get things done quicker and to complettion... Since I know the Indie side is rough be alone and finding a reliable team. Plus small Commercial interests that want to use Torque..would see this as very valuable..

Any more thought??

#4 I've had to be very careful in formulating this post, since there is a fine line between a discussion, and exposing business strategies :) I ran the GarageGames Commercial Support program for more than a year and a half, so this is from both research and experience.

Your two biggest weaknesses in your current plan are these:

cost/work estimates -- $25/$100 may seem like a lot of money, but it doesn't even scratch the surface of what your total costs will be. Do to the nature of most "support" we as individuals use (calling up your cable company and getting the guy following a checklist, calling some other company and getting an overseas connection to a support outsource company), everyone thinks that support is easy, and therefore should/can be cheap.

It couldn't be farther from the truth--especially with something as complex as Torque. An engineer that's capable of debugging and troubleshooting anything other than TorqueScript typos (a bit of sarcasm there of course) is an engineer that could most probably be earning between $45k and $120k working as either a game developer in a studio, or a consultant. You are pricing a single incident at $25 US--from experience, an "average" incident is between 2-4 hours, and that's for the easy ones, giving you an effective billing rate of between $10 and $6 per hour, US.

I could go on and on and on with support examples, but suffice to say you won't be operating successfully long at those price ranges.


risk mitigation -- Another area that is extremely important. User/Developer support is a service, not a product, and the business plan around the concept needs to be built up as such. You mention 24 hour response--what happens when you can't meet that because you have 2 open support cases right now that you estimated to take 2 hours each, and they are taking 6? During that time, you get 3 more cases entered, and aren't even able to respond to the initial case report to collect the information you actually need (you rarely get the information you need to troubleshoot in the first couple of email exchanges--just look at the forums here).

Following this scenario leads to the concept of having a support structure system that's automated, including a (populated) knowledge base, as well as Tier 1 and Tier2 (and probably even Tier 3) assets on staff to properly escalate support requests as they come in. If you're best troubleshooter is spending a majority of their time collecting information around an incident, you are wasting valuable resources...and if you are flooded with support requests that only require Tier 1 support but you don't have Tier 1 support and escalation procedures in place for when they are needed already in place, you again become bogged down, and lose revenue.

Finally, you'll find that a majority of your cases at this price point are not in fact true support, but education. You aren't actually supporting Torque, you are teaching Torque--because a very large amount of "bugs" are simply an end user not knowing enough about Torque to use it as designed--I'm not complaining here by the way, I'm simply reporting actual experience with running a support program.

At GG, it is mandatory that any commercial requests for being part of our support program first send their team to a commercial boot camp. This isn't a "we want your money" issue--the policy only came about after the first 6-8 months of running the support program, when we found that a very large portion of the actual support incidents were teaching the customers how to use Torque properly.

One more final thought about risks, and support:

You will invariably find yourself getting support requests at the very end of a project's life cycle--it has to ship in 2 weeks, and XXX doesn't work. It's going to take quite a bit of time (much much more than reviewing 5 pages of code) to figure out what's up--and what do you do when "what's up" is a poorly designed system that will take months to re-design and re-implement? Your customers will not, by any means, be happy with what you tell them, and in the long run you'll start needing to implement restrictions on the service you provide, or deal with the PR issues when they complain on your forums/elsewhere.

#5 In addition to Stephen's very well-thought-out response, I have a couple of points as well that I was thinking about but didn't have time to post (still have four pages on this draft before I can start my second 25 page paper and playing the avoidance game).

The hosting model is not a remotely direct analogy as they do not teach you PHP or support your PHP codebase or learn Dreamweaver. They make sure their servers are running, your e-mail seems to be operational, and such. They may offer contract services to make sure Moodle is operational, but they are not going to be a server and course administrator for your online school.

Unfortunately, the support model proposed, even in its revised form, does not stop at making sure Torque is installed, Visual Studio setup, and that the demo can be run. It can often lead to teaching people to use visual studio, how to set breakpoints and debug code, how to navigate a complex artpath over e-mail, the basics of C++, how C++ differs from TorqueScript, why they can't import TorqueScript into TorqueX and automagically convert their TGB games to TorqueX, project intricacies for people who want to use CodeBlocks and Mingw on Windows to keep their Linux port closely inline with their Windows project, how to setup subversion or Overlord, supporting third-party integrations like the MMOKit or Browser in TGB, extending Killer Kork or Advanced Camera or vehicle physics, integrating Newton, PhysX, ODE, or Tokamak into TGEA, converting GL-specific render code to TGEA for resources dealing with the RTS Kit, integrating WxWidgets because they don't want to use the default Torque GUI, networking physics in TGB, algorithms for faking shaders on older hardware in TGE, issues with Immersive AI or Modernization Kit, multiple problems with resources designed for TGE 1.2 and their implementation in TGE 1.5.2, dropping TGB into TGE for sweet GUI's, the smoke particle problem in Torque for Teens, etc.

As Stephen noted, I speak from experience as well, though definitely not for as long a length of time as he has.

It makes the concept of support an extremely difficult topic of discussion.

#6 Hi Rigo,

This is a very interesting idea and despite of all issues that your proposed model have I guess that thinking a little deeper can help to overcomes them.

One question, (David and Stephen please tell me if I can't write this here). What about having a site with how-to style tutorials as part as paid support?. I think is not a secret that the big issue with Torque (TGB in my case) is the lack of proper documentation, I had lost enormous amount of time just locating or figuring out how to do something. I will be glad to ask an expert about a particular issue or even better, just reading how to do a frequent task.

@GG people, please don't get me wrong, I think that you're doing a great job with your products, honestly I just think that your products are developed faster than the documentation. The advantage is to have new versions very fast but it is difficult for a newbie like me just find how to do something.

#7 Ok, after mulling this around in my head for a week or so.. I am gonna put out another revision to this idea of support using everyones excellent input :)

A couple of directions I can go with this...instead of just trying to work out a support only structure. It sounds as if I should view this as more of a consulting type of service. And should specify exactly what you recieve from a customers perpective which is a block of time.

So what I can do is:
- offer single Question/scenario/issue only support locked down to up to one hour of support by a Torque specialist
- offer consulting based on hourly rates as needed for higher priority/commercial needs.
- teach classes or bootcamps, since that sounds like what is mainly needed for most indie users issues.
- possibly offer memberships for reduced support costs(per hour rates) plus bonus material..like videos, extra documentation, content..etc.

So this is the revised support services:

Level 1 (Indie) Support:
- single request/or issue (can be mutliple questions on a subject)
- email only
- Support any type of issue in the covered area, no 3rd party integrations/support
- Torque Tech Specialist level (some c/c++, TorqueScripting, teaching)
- Up to One hour block of time working issue/providing answers (no SLA)
- If lvl1 cannot assist there is no charge
- With clients permission, issue can be worked longer at the rate of $25/hr or escalated (higher pricing)

Pricing: $25.00

Level 2 (Indie or Commercial) Support
- appointment based / Phone or possibly on location
- Training, code review, tech help...
- Engineer level (c/c++, TorqueScripting)
- One hour block of time (no SLA)
- If lvl2 cannot assist there is no charge
- With clients permission, issue can be worked longer at the rate of $50/hr

Pricing: $50.00+

Also offer:
BootCamp (Indie or Commercial) Training
- Online or offline
- training in all areas related to torque
- Single Session or Day long class (4-8hrs)

Pricing per student $50-300

As far as a memberships idea I think the only thing that can be added that GG doesn't already have is training Videos, further specific documentation and maybe a specialized KB. But the forums for the most part here do cover a ton of issues. Though many do not have resolutions.

By offering support this way it should alleviate the costs on the business end by locking down really as a consulting support service and the time of assistance.

Benefits can still be:

Business end
- Costs are covered since mostly everything is hourly based
- Tier1 and Tier2 support + a training option can be offered
- both Tiers can provide any assistance as needed, possibly code fixes, changes..
- removal of SLA. or possibly a client can purchase with an SLA for higher costs

Client end
- Faster support response time (no searching through forums..etc.)
- Purchase as much as needed for your specific project, and still be somewhat Indie friendly pricing
- Your specific project support help.
- At both levels of support We can offer not only coding, but art pipeline, ..etc.
- Dedicated support staff always available
- No searching for decent consultants for your project

And some Cons I can think of with this scenario

- possibly having a lot of unanswerable issues come in (which take time to check into) without a possible charge
- High Expertise or experience is required for techs and engineer lvls

@Stephen, Does GG still offer support? last time I called a year ago or so I was told it is not offered anymore even with training. And is this something GG would be interested in partnering on? Or would advertise?

Anyways does this sound reasonable and Indie or commerical friendly? Would any of you pay these rates on your projects?

#8 Support is still relegated to the forums. We try to answer questions, but there are so many, and so many variances (look at the questions that appear here daily, many of which are game-specific). Now, if you were to provide support on the stock engine, which could include not helping people update resources (as that can quickly burn several hours at $25-$50 and...just maybe...will negate any cashflow since you have specified that the user does not have to pay if you attempt to help them but cannot find a solution.

That is a difficult business to be in, especially if you advance it through tiers of escalation, work several hours (tying up your techs so that they are not helping other people, especially if you offer telephone support) and are unable to solve an issue because of scope. Scoping in support is an extremely difficult business. Often times something seems like it should be trivial and ends up being a major undertaking that costs many man hours. On top of that, with a money-back guarantee on support, you are opening up the possibility that the longest support cases, which are necessarily the most difficult, may be the ones that you never get paid for and thereby not being free enough to support the smaller incidents that are sure-payments.

I can easily see a team not understanding the scope of implementation--and a new support staff not understanding it as well--undergoing a large-scale support issue that takes a large number of hours, multiple escalations, and ends with the team realizing that it is unrealistic in terms of a support model like this since it is unsolved (whch means that they pay nothing) and it should have been a contract solution...which they may be able to get for less or a comprable amount to tier 5 support at many hours. So, you've effectively taught one team to scope their support effectively while making no money on the actual support you provided. Perhaps the next team will scope more accurately; perhaps not.

Just a thought on that aspect.

#9 Hmm..I see what your saying...

I am really thinking in different terms. Support would mainly be on a contract hourly basis. There would be no guarentee of a resolution. But a gaurentee of assistance with your issue. It doesnt mean we would solve a problem every time. It only means we can provide knowledgeable expertise in furthering your project and hopefully getting past the issue in the process or providing assistance with a work around solution. In essence this is consulting as a consultant will provide expert or professional advice in a situation but does not always fix the situation. Though this is still a support type of roll..

There is no worry about loss because we would know up front if we can support your issue(s). If we are able to provide some quality support on the issues at hand aka we have knowledge in the area (remember not necassarily solving it still). We will take the issue on a paid up front pricing on an hourly basis. And the client can stop paying when they have recieved enough help at anytime. But they have paid for the current hours up front so again no worries. We can offer to escalate the issue to our 2nd level and if they look at the problem and can't provide assistance either, then we simply stop there and do not take the issue. So there is a small amount of time to look over the issue or request more information but that can be lowered by having users go through an extensive web form since we are mostly taking request in certain areas.

hope this clears it up....maybe I should just call this consulting now and forget the whole support structure.. :)

Anyways thanks for the thought they are much appreciated...

#10

Quote:
There is no worry about loss because we would know up front if we can support your issue(s).

Think very, very carefully about this. From 3 years running Commercial Support here at GG, plus 4 years of personal development with Torque, there is always risk associated with thinking you understand a problem set and being correct about how to solve that problem set.

While I'm posting, I do want to correct something said above--GarageGames does provide custom support still to qualified Commercial accounts, but it is by negotiation only, and quite expensive (out of the range of the large majority of Indie developers).

We've looked at dozens of ways of trying to provide cost effective support at the Indie level, and have never found a sustainable business model that can both meet the needs of Indies, and at a minimum pay for itself (much less actually make a profit). As David said, the forums, as frustrating as they can be sometimes, is the best sustainable strategy for Indie support that we've found.

#11 Good catch, Stephen! My statement was for general-level support, not special contracts.