MTM2.com

What follows are a few guidelines that might help a track or truck builder get the most out of the beta process. The discussion is 'couched' in <i>track talk</i> but the same principles apply just as much to trucks, and even utilities, as to anything else.

Contents

o <a href="#Purpose">Purpose</a>
o <a href="#Good">What is a good track?</a>
o <a href="#Maker">The Maker's role</a>
o <a href="#Tester">The Tester's role</a>
o <a href="#Conclusion">Conclusion</a>

<a name="Purpose"></a>
Purpose

The purpose of beta testing is simple. Beta testing gives other people an opportunity to comment on your work before the final release. The aim of these comments should be to help the maker create a better track as well as eliminate the need for 'fixed' versions.

The beta testing process can mean a lot of things to different people but there is one thing they all have in common. And that is: building better tracks and trucks. One thing it is not, however, is a substitute for <a href="http://cownap.com/~traxx/traxxsch.html">Traxx School</a> or the <a href="http://cownap.com/~mtmg/repaint/">C-pod Repaint Tutorial</a>. If you have not done either of those, then stop right now and do them. If you have not done those, then you are <u>not</u> ready for beta testing. Once you complete the starting tutorial for the area you're working in, then come back here with your finished products.

<a name="Good"></a>
What is a good track?

In mtm2 the question of what is a good track is almost impossible to answer since there are so many different styles of game play. And it is complicated by the fact there are probably as many opinions and personal preferences as there are tracks. The mtmg has collected some feedback in this regard.

http://cownap.com/~mtmg/traxx/good.html

http://cownap.com/~mtmg/traxx/rumbles.html

That does not mean there is no solution. If a proper beta process is followed, then invariably better tracks are the result.

<a name="Maker"></a>
The Maker's role

There are several things a maker can do to get the most out of testing.

1. Make sure the track works properly. That means, at the very least it should have road textures in place, a map, and, unless it's a rumble or drag track, at least two checkpoints.
   
2. Upload the work to be tested. This may seem obvious but it can't be tested if it's not available. Transferring files over icq, for example, is fine for small test groups. But for a larger audience, upload to your own web space or to the cownap/mtm2.com download page. Do NOT email large files.
   
3. Mark its type as 'beta'. That way, people know it's unfinished work. The average downloader will be far more patient with you if they know you're looking to improve the work rather than pass off something that's sub-standard. You can also include 'beta' as part of the file name.
   
4. If you want public input, then start a review in the beta talk part of the forum. (If you do not start a topic, people will assume you are testing privately among your friends or team mates, and that you are just using the download page as a way of sharing your work. This is fine of course but we ask that you upload the finished work here too so we know when it's done and so we can remove the beta from the main page). In short, starting a review is your way of saying you want input. If there is no beta post it is assumed you do not want general feedback.
   
5. Prepare a list of things you want people to consider. Are you looking for texture misalignments? Are you looking for model misplacements? Maybe you're looking for course ideas? Whatever it is you want, be sure to let testers know where they should focus their energy. Do not say "tell me what you think." It is your track. It's up to you to tell would-be testers what they should be looking for, not the other way around.
   
6. Be prepared to listen. In many cases you will receive input and suggestions you were not expecting. But understand, many of the people providing feedback know what they are talking about. Bad things happen when you ignore good advice. Testers will test, and they will try to provide sound recommendations; but it is not their job to beat good sense into anybody's skull.
   
7. Do not expect testers to make your track for you. It is their job to find and report problems, or maybe offer suggestions. It is not their job to make the track. After all, if they wanted to make a track, that's what they'd be doing; they'd have their own track and their own beta thread.
   
8. Stop working on the project. There is absolutely nothing worse for a tester than to take the time to run the course, make notes, write up the report, sometimes take snapshots - there is nothing worse than to do all that only to be told "oh, I fixed it after I uploaded." Don't waste people's time. If you know something needs fixing, then fix it first before you upload a beta version.
   
9. Be patient. Test driving is an onerous task. People have lives that don't always include mtm2. People will get to it if you allow them enough time. If you can't hold back, then start a second project. However, do not upload a second beta for testing until the first one is complete. One test project at a time please.
   
10. Be thankful. Even if the feedback you get isn't exactly what you're looking for, somebody has taken the time to test your work and offer comments. Sure, nobody is suggesting you need to be gushing and overflowing with compliments and sending gifts and presents for the attention to your work, but a show of respect is due fare whether you use or reject the opinions tendered.
    
11. Always remember and never forget, this is your work. Suggestions will come and suggestions will go, but the quality of work is ultimately in your hands. Consider all input, then weigh it against your own likes and dislikes. The finished product will have your name on it. Be sure it's something you can be proud of.

<a name="Tester"></a>
The Tester's role

1. Beta testing is not just a preview of an upcoming track. You are being asked to find what works and what doesn't. "Nice track" is not useful feedback. If you think a track is good to go, then say so and say the reasons why.
   
2. Be mindful of the maker's feelings. In most cases they've poured heart and soul into their work and don't need some wise guy to come along and tell them it stinks. If there are problems, explain what they are.
   
3. Keep it constructive. There are a lot of times a maker is unaware of the errors s/he is making. A tester's job is to show the way, to guide the maker to a better product. It is not to criticise and tell them how wrong they are... <i>even if they are</i>.
   
4. Balance the feedback. If there is something wrong, try to propose a solution.
   
5. Balance your evaluation. By it's very nature, beta testing dwells on the negative. It's only natural. You can't make it right if you're not allowed to say what's wrong. Still, if something works, if something stands out as being well done, then let the maker know it. People need to know they're doing things right too. And who knows, maybe they're not aware how much you like it and might take it out if you don't speak up. It's easy to find fault. It's just as easy to pat somebody on the back.
   
6. Try to be specific. Describe the problem, try to be accurate about locations. Do not use pronouns in your descriptions.
   
7. Don't be shy. Nothing is too big or too small to mention.
   
8. Who made it doesn't matter. A problem is a problem and if you find one, mention it.
   
9. Be understanding. Not every one of your suggestions will make it into the finished product. Opinions and preferences vary, but that's no reason to stop testing somebody's work. Your input is valuable even if sometimes it's used for no other purpose than to affirm what's already being done. After all, that is helpful too.

<a name="Conclusion"></a>
Conclusion

Different people work different ways, and as a result there are many different flavors of beta tests. Roughly, the stages can be broken down into definable steps.

• pre-alpha preview
• alpha
• beta
• beta
• beta
• release candidate

Some people will use all these steps. Others will use only the final one or two. In other cases, a person will begin by using all of them but as they improve they'll come to rely on one or two steps only. In all cases, beta testing is a learning process both for the maker and for the tester. The end result of that learning should be more fun in our game.

I knew we'd forget something in all that.
<a name="addenda"></a>
Addenda

• When testing, it is recommended that the beta track or truck should be placed at the top of the pod.ini list. This is helpful for detecting bad or corrupt files that might otherwise go unnoticed because they'd be masked by the pod order.

the first link for "What is a good track" contains good ideas submitted by several people. the only one i didnt undertand was:


whats the Noah Phenomenon (hehe n00b here).

The Noah Phenomenon means much flooding. Mostly caused by trucks with excessively high vertex counts and can be cured by turning off reflections in graphic options.

oh yea, i remember that happened to me in crazy 2002.5, but it worked if i turned reflections off. reflections always cause strange problems for me anyways.

Hehe good catch, Phin.