Tips From Phineus Reviews & Beta Reports First things first : reviews and beta reports are NOT the same thing. Reviews should be designed to inform people about what they can expect from a track before they download. Beta reports should be designed to help a track maker refine and improve his/her track. People participating in this process should remember the distinction. I am writing this page because recently a couple of people had trouble understanding these concepts, problems dealing with constructive observations, and, after all had been said and done, asked for help but didn't really want to hear the truth. Now, I am all in favor of being tactful and considerate of a track maker's feelings, but I also believe that if a track maker is not prepared to receive the responses he or she gets - the good and the bad - then perhaps it would be best not to ask for opinions to begin with. A good review should : Try and keep the same look and feel with several reviewers. Keep in mind the purpose of a review is to give the downloaders an idea what the track is like before they download it, not to criticize the author. Especially new track makers. Different people like different things from a track. Point out the good with the bad, but get the essential information in at the top of the review, like setting, layout, etc. You can go on to point out special details you did or didn't like, but don't get too carried away. Remember, the reviews are for the downloaders, not the track makers. Concerning the 1-10 rating scale, be thoughtful of the track makers feelings. Few tracks deserve a 1 or 2. Most tracks should fall into the 4-8 range. Reserve the 9 and 10 ratings for exceptional work. If there are errors in a track or it simply does not work, either don't review it or e-mail the author and ask permission before you post. Triple check your review for spelling errors and accuracy. A good beta report should : Look for flaws in the track. This should include any and all technical, functional, or visual problems that you find. And, don't forget to test specific areas the track maker points out to you. Make an assessment of the track as a whole. Yes, whether or not you like a track is important, but this kind of assessment is not restricted to personal preferences and should extend to include things like derivability, texture usage, consistency of motifs (if any), etc. Think of possible ideas. These may include anything from nifty little touches to major reworkings to something the tracker hadn't even imagined. Don't be afraid to be too obvious or too detailed. Give a summery of your assessment. This is not the same as your initial assessment. Rather think of it in terms of the 1-10 rating system. Give your idea and then go into some detail why you believe it deserves the ranking you've assigned to it. Case study : a review Anyone can say "good" things about a "good" track. There is no art to reviewing a track that is near perfection. Likewise, very few people will have a problem talking about a track that locks up their system. The trouble begins, however, when you encounter those gray areas in between. The following example is about that in between area of track reviewing. This actually happened and I strongly recommend NOT to get yourself ensnared in these kinds of situations. The names are changed because this is a tips page, not a gossip column. I'm using it as an example because I think there's something to be learned from it. So.... Fred makes a new track and posts it for download. Fred asks Barney to review it. Barney agrees and downloads the track only to find it plagued with problems. So, now, Barney finds himself in a bit of a tight spot. He has promised a review but hasn't the heart to bash Fred's work. After all, Fred has put so much of himself into this track that Barney is sure any harsh words will crush ol' Fred's ego. Barney plans to ignore the situation in the hope that it will fade away. But! We all know what Fred is like; he pesters Barney about the review to the point that he doesn't know what to do. Barney's conflict is very real. He doesn't want to criticize Fred's work, but he doesn't want to mislead potential downloaders. Not knowing where to turn next, Barney asks Phineus what he thinks on the matter. Now, if Phineus was sharp, he would have butted his nose out big time. But, he's sometimes rather slow and dim-witted and, so, offers to look at the track. To make a long story short, Phineus suggests to Barney to post a review that goes something like this :
Genre: Circuit This track has all the markings of a green, wet-behind-the-ears, rookie track maker. For example: computer trucks don't work, helicopters don't work, textures are mis-aligned (sloppy at times), terrain jaggedness extreme, checkpoint numbers are mis-cued, models are mis- and dis-placed, jumps are too long at most spots, the race line isn't always clear, and the trains don't follow the terrain (keep it flat!). Having said that. The overall layout is excellent, the banked corners need touching up but are generally fine work, and the music keeps driving you onward. This is Fred's first track and I'd like to see two things from him. First, a fix for this track. Second, his next one. If this guy can pay attention to detail, we're going to see some wild things from him. Gameplay: 3/5 Visuals: 1/5 Layout: 3/5 Custom: n/a This track rated 5 /10
Now, Barney can't tear himself away from his initial feelings of kindness and decides to re-write his review entirely to make it sound softer. Phineus quickly objects that the downloaders are the target audience here, not the track maker; it wouldn't be right. Barney takes offense at this apparent jab at his integrity and becomes upset with Phineus. Meanwhile, Fred is still after his review, so Barney shows the "Phineus" proposal to him. Guess what? Fred is upset with Phineus too. In an effort to make amends with everyone, Phineus agrees to a tour of the track under the confident guidance of Fred. And, after an hour or so of falling into ditches and not being able to get out, after looking at sloppy texture work and a very roughly made terrain, after ignoring check point problems and trees that haven't been set to facing, after discovering a new lag problem not noticed before, and after listening to many many rationalizations about why these things were done on purpose, Phineus accepts a change to the proposed review. "Yes," he admits, "you can take out the wet-behind-the-ears part." In conclusion, a five is not an eight. And that's how fives are likely to be described. The track works - which is more than can be said for some other tracks - but it needs work. Yes, reviewers should be kind and considerate. But, please, track maker's, don't shoot the messenger either. P.S. I am really happy to say that all friendships remain intact. So, after everything has been said and done, good sportsmanship wins the day. Case study : beta report 1 The above review gave rise to a considerable amount of talking between myself and the track maker. Although, from certain perspectives, the review can seem very harsh, the track maker recognized that it was not a personal attack and eventually grew to appreciate a great deal of feedback. It was during these conversations that I learned he had received one beta report that went something like this:
....I hate it and love it!! I love it cause it makes me concentrate during the whole lap, on the other hand I cant even take a break while racing to take a puff off my cigarette
This kind of response might recognize a degree of intensity, but it does nothing to help the track maker improve or make refinements to the track. And, as a review, it tells nothing about what the track is like. If you agree to beta test a track, then you are also agreeing to provide some useful commentary. Please do your part, so track makers can do theirs. Case study : beta report 2 This is an actual beta report I gave to a guy. For the most part, it follows the guidelines mentioned above.
Beta track report - From Bedrock to Redrock. FIRST IMPRESSIONS The track is made/put together at the same level as, say, Pine Grove by Gizmo : stock textures and stuff but used in a new and different way. That's a compliment, in case you couldn't tell. Yeah, it would be easy to compare it to more similar tracks but any significant discussion would get lost in quibbles over similarities and differences. btw, what's a fast lap time? I did just under three minutes while sight-seeing, but I don't know how much I could clip off that. DETAILS - The transitions between altitudes is much improved over your last track. - Road width is consistent throughout - some people with short attention span or something have the roads peter out near the end. Good job ! - Roads are near perfect. Bumpy for no reason I can see in a few spots. Oh and near cp 5, you have that motocross sequence of hills/ramps. Is that what you were trying to do? or just to break up the straight? If the mx, you might wanna use the curvature control in terrain edit mode to round them off when first making them if you like. Overall, pretty damn good. - Trees are randomly set to collide and no collide; you might think about setting trees to no collide and then place an object box for the trunk. I know it's a lot more work, but the end result is worth it. - Speaking of object boxes, I ran into one nearing the end of the track. Dunno what gives with that - A few trees are not set firmly on the ground. They hang just off the edge near the water (on the last quarter). - A few (and I mean only a few) textures are mismatched. I don't know if that's a limitation of excavation but you can see them on a few corners - Computer trucks have trouble near cp 5 - The roof of the tunnels have a few openings in it/them. Is this for helicopter purposes? I'm guessing, yes. - Watch the extra long straights. - Somewhere shortly after cp 5 (or is it 6?), anyway you know where that big jump is and the landing area is slanted to the left. Well, my personal preference is to land flat - horizontal to the horizon. But, please take this one with a grain of salt. It's a minor detail and more of a subjective response than any real concern. SUMMARY I get the impression you know what you're doing. You seem to have a good grip on things. I mean, why take somebody else's word/view when your own seems more than capable of making the evaluation.
The name of the actual track is not really the important thing here, but you should take note of the kinds of things being talked about and how suggestions are worked into the whole thing. Also note how I try to describe "where" in the track the things are that I'm trying to talk about. Pin-pointing locations can be very hard to do at times. In one case, I actually opened the pod up in Traxx's Pod File View and told the track maker the x, y and z values so he would know exactly where a hidden texture problem was located. In both cases, the track makers were appreciative of the report. So, the point I am struggling to make clear is this : we are all neighbors here in the mtm community. Those who provide reviews and beta reports would do well to keep the track maker's feelings in mind. Those who receive responses to their work would do well to take all suggestions under "advisement"; then go ahead and make your track. If you can understand this, then you should be able to understand why Yeastman signs his work, "Unity! As one stand together!" We should respect the role or spot in which we place our friends. It's not always easy pleasing everyone. Apr 99