The road to become a reviewer...

- A monkey is a deer in his father's eyes - Arab saying

Intro: why reviews are made

So you want to be a reviewer, eh? Good for you. UT2004 has a strong community of mappers and even now, new maps are released on an almost daily basis. All mappers have their own ideas they want to implement, and they have varied skills of UnrealEd. The big majority of these people honestly try to make their maps as good as their skill and patience allows them to.
On the other hand, you have the gamers. These vary a lot as well: many like onslaught, others swear by deathmatch (even after 10 years), yet another group consists of flag capping maniacs, and so on. Within each gametype, the audience is more like-minded: everyone wants to play "good" maps.
So far, everything seems perfect. The discussion starts with the question on what makes a good map, as there is no universal answer to this. To make matters worse, hundreds of maps flooding in from all corners of the world, making it impossible to keep an overview of the available maps and how they are constructed.

That's where we come in. Reviewers are to the community what reporters are to Real Life. We provide a stable evaluation by means of an independent, profound article about the map. You can compare it with surgery: just like those doctors open up those cute guinea pigs to point out the organs, we open up the map and make notes on what we find.
To avoid misunderstandings: we are not beta testers. If a map is submitted, it is presumed done, and the mapper should agree to that fact. Re-releases of maps are okay (they happen all the time), but we dedicate a lot of time to a review, so we don't like to hear that this work becomes obsolete.

For a review, both the mappers and the gamers form the audience. Mappers are the first group. They can benefit from another map's review as a live practice for their own work. They may want to learn from fellow mappers' mistakes to avoid them theirselves or just to get a better insight in proper usage of gameplay and visuals. You can assume the map author reads the review, but he doesn't get a special treatment. Reviews are public letters, not a personal note to someone. If you have something personal to say to the particular mapper, you can always write an e-mail.

Anyway…gamers are the second group. In search of a 'good map' they become attracted by the screenies or the final grade. Or maybe they want to get to know a map better before downloading (eg. the 56k-people). No offence to this group, but they are only an attendant audience for the write-up. On many occasions, you can help out this group relatively easy with a quick summary and some screenshots. The mappers are the ones who need to know how the aspects play out, so they are the ones you'll do the most writing for.

These two groups differ a lot, and both parties have completely different priorities on a given map. Beta tests (should) unite these groups, but the gap remains visible for the reviewer. Reviewers take their place somewhere inbetween these groups, and try to cater to both groups. This causes them to put accents on different aspects of the map. Mapper-side reviewers provide deeper information on the used methods to make the map and are stricter on misplaced elements. Portions of these reviews can be tough to understand without knowledge of UnrealEd. Gamer-side reviewers (like me) keep most focus on the gameplay aspect, and keep more time trying to grasp the flow than that they are searching for misaligned stuff. In both cases...we're freaks ;-)

The basics

Purpose: your main goal as a reviewer is to deliver a correct view of the map. Normally, everyone has to be able to recognize which map you're talking about just by reading the text. It's important to understand that all reviews are opinions! There is simply no way you can state for a fact that one map is better than another one, so don't bother trying. Instead, separate what the map contains (facts) from how you think it works out (opinion). It's a good idea to show this to the readers by adding a few "I think that…"'s, "The way I see it, …"'s and even some basic "IM(H)O" 's.

Relativism: the length and choice of words are just as important as the actual content. If you only notice errors when you're thoroughly looking for them, it's not fair to spend entire paragraphs complaining about them. Highlight what you remembered the most from the map and summarize details into a few sentences. You don't even have to mention everything, as long as it's something you won't notice in a regular game, or simply doesn't have (eg.: in this review, I knew that when you fell into the lava, you died before you even hit the stuff. I didn't mention this because you rarely fall into it in the first place and there was plenty of other stuff to talk about).

Comparison: It's a very good thing that the UT-series ship with a big variety in stock maps. They all have different themes, gameplay, visuals, and so on. This makes the stock maps good grounds to fall back on. If you're having trouble describing something, refer to stock maps that gives you the same feeling about the subject. You can even refer to other custom maps if you want, but make sure you pick one your audience is likely to know.
Retail maps also serve as the standard for grading things. Take performance, for example. Your audience wants to know how smooth the map will run, even though everyone has a different computer. That's when you start comparing things. Personally, I will never simply state that a map has bad framerates. I always go with the "compared to stock maps, it has better/equal/worse performance" method.

Author: reviews are never anonymous. Though the map is always the center of discussion, it often tells something about the reviewer as well. Readers will eventually compare the writings with the map and come to a conclusion about what you say (AKA: a reputation). Collegue reviewers will often give advice, comments and suggestions, especially when you just start out. It's up to you whether to follow this or not...

Copyright: to get things clear...we haven't played every map in the existence of gaming and we haven't heard every music track in the universe. It's always useful information to know whether a map is based on another map, but we rely on the readme here. If it doesn't contain anything, we don't assume anything. If it turns out to be an unauthorized rip from someone else's work, you can definately expect us to mention this...if we discover it. If you're a mapper, I strongly urge you to read this very important thread that came under my attention rather by accident.
Unfortunately, illegally ripped music is very possible in a map. Just because maps aren't meant to be a way to distribute music files, doesn't mean it's not illegal. We can't be held responsible for any abuse in this way and are in no way related to the RIAA. However, we trust that the mappers are aware of what the possible consequences might be...

Reviewing style: this is almost completely up to you. Nobody's gonna criticise you just by your angle on a map. As stated earlier: reviews are opinions, so there's a pretty good navigating space to write your writings. You want to tell about the matches you've played in the map? Sure, go ahead. You consider yourself the 'all-seeing eye' on what's going on? Write ahead. Whatever your approach is, it's a correct one.

Technical style is a dilemma. For convenience sake, we assume that readers know enough of UnrealEd to understand basic terms like Blocking volume and aligning. It's not a "look at my knowledge"-contest, though. Prefer phrases like "bots don't jump on the altar" over "pathnode 27 has to be set as a jumpspot". Knowing how to map is a plus, but by no means obligatory. Some of us reviewers have never even opened up a map in unrealEd! Just remember that mapping takes a lot of time. How would you feel if you spend days, weeks or even months on something, after which some short-sighted would-be writer humiliates you in public? Just to say...show some respect. They deserve it.

Skill: unlike UnrealEd skill, gameplay skill is a requirement. If you don't know how to play a certain gametype, you won't be able to write anything useful for a fact (I don't think anyone is gonna argue about this). However, knowing what makes a good map is not that easy. Sure, nobody can argue with you on your own thoughts of what makes a good map, but if you're the only one who thinks so, I can predict you won't get a lot of positive feedback. And still, all you really need is one simple question: "why?" Load up some good maps, and ask yourself: why is this a good map? What factor makes me like it? Read other reviews, and the comments on the map. Why do people think what they think about it? So a map has good gameplay...why? There are no absolute answers out there (hence the fact that user scores can fluctuate wildly), but the factors for a good map are pretty constant within a given gametype.

Also: you can reach a more advanced audience if you know how to play the game. Learn how to lift- and shieldjump, practice your dodges, and so on. How is this subsection of the game provided for? One of my unproven theories is that the gaming skills of the mapper are directly proportionate to his/her mapping skills...at least on the gameplay department.
Conclusion: don't be affraid to turn down a review if you don't know the gametype well. It's worse to have a bad review than no review at all. This might sound strange, but you could have used that energy and analysis on a different map on which you could write some useful stuff. Don't worry about a shortage of maps; by the time you finished a review, at least 3 more maps will be submitted to the map hosting sites ;-)

Structure: despite your personal style, you need to follow a basic structure. Guidelines, so to speak. The audience wants to know certain things about the map, and it's your job to mention it. Keep on reading and you might just find out what's there is to it…

The different steps of a review

0. before the map starts: so far, all maps are equal. You download the map and install it. It's important to begin by checking out the readme. These contain valuable information about the map, from known bugs, update history, other maps by the author, wether it's a remake, how many beta's were released, and so on. Anything extraordinary should influence your writing. First maps require more constructive criticism, you should mention extra help on the map (e.g. an outside musician or texturer), and things like that.

There is one thing I'd like to spend a couple extra sentences on; by lack of a better gametype I'll call it side-gametypes. These are maps that aren't meant to be played as a normal map, but are aimed at certain mutators or different gametypes. Sniper maps are a good example of this: these kinds of maps are so fundamentally different from regular deathmatch maps you can't even compare them against each other. Check out this thread: what started as a simple notification that I wasn't going to review this UT99 map, ended up as a whole questionnaire on what makes a good sniper map. It clearly illustrates the importance that you need an open mind as a reviewer. I mean...if I had written a review on this map, it would have failed badly. However, this is one of the best and popular sniper maps out there. We can't and shouldn't change their view on the game (a view of camping and sniping). All we ask is that the readme states that it is - in fact - a sniper map, and made to be played by sniper rules...And preferably submitted to a reviewing site where they know how to deal with this kind of maps ;-)

1. gameplay test: this is the easy part of the review: start the map and play it just like any map, with the settings and bot skill you're used to playing. Put the thought of reviews aside and frag away...Or cap away…Or assault away…Or… well, you get the idea. Keep playing until you are completely familiar with every part and you know how a typical game is played out. After the first game, think back on what you remembered from the map. I recently learned that in an application, it takes the manager an average of 2 minutes to decide wether to hire the applicant or not. After that, (s)he is mainly searching for reasons to backup this impression. Now I wouldn't dare to state that this goes for maps as well, but I must admit that I've rarely saw my view on a map drastically change after the first impression (DM-UCMP-Contrast is my best example of an exception). All in all, there are a lot of mental notes to make after the first acquaintance. This doesn't mean you should only play the map once (at least not when you're certain you're gonna review it); keep playing, but start to observe more about the environment.
A little note on framerates: make sure you've got the framerate display on your HUD (command: stat fps). This is a most useful command for objective comparing the frames per second against retail maps. stat hardware shows the amount of polygons within view; this often indicates a reason for low framerates.

2. visual test: you start this phase by getting rid of all the bots and turning up the detail settings (if they're not maxed out yet). This is the modus in which you're going to check out how the level looks and sounds. Take your time to look around for misaligned meshes/textures, and places where you can get stuck. What's there to say about lighting and lightsources? Are the blocking volumes in place? (use behindview to check, in case you're not sure) If possible, try to find out how well the map lends itself for trickjumping and/or exploiting opportunities.

Note: checking the item layout is also best done without bots that hinder your analysis. This usually brings up some mention-worthy details.

Note: this mode is also the best one to make screenshots. For UT2003/4 reviews, use the togglescreenshot or showhud command to get your HUD out of the way. In UT99, you have to go to 'Options -> Player setup' and check 'Play as spectator'; for teamgames, you have to uncheck 'Show team info' in 'Options -> Preferences -> HUD' as well. In all UT games, the fly, ghost and walk commands are convenient ways to get into position for a good view on things.

3. writing the review: now that you've got all the info and - hopefully - an opinion you can back up with a good amount of arguments, you're ready to start writing. Before I outline the paragraphs you'll need to write, you must check the local settings for the site you are reviewing for. UP, mapraider and Nalicity use standard named paragraphs, which is a good way to keep your review focussed. Just because Insite doesn't enforce this doesn't mean reviews are chaotic. Either way, following paragraphs are the standard ones...

3.1 introduction: the first words to the audience are always the hardest, which is another reason readme's are important. Here, you can either give an overview of the map, set the mood with the background story (even the lack of a story is worth telling about), start out with your first impressions or even which terrible real-life issues you had to overcome to bring forth the review. As a rule of thumb you keep the actual reviewing on a distance, but don't worry if you have to break this rule. Just make sure the audience is getting warmed up for what's to come…

3.2 Atmosphere, Visuals & Aesthetics (AVA): in this you describe the standard look-and-feel of the map. Describe the theme as you perceive it with the most obvious features. Meshes and textures are the most classical. How are they applied? Do they connect in a correct way? And are they chosen in a way that they enhance the theme? Lighting, for example. In real life, lights are easy: turn on a lamp and your entire room is lit. In the game, good lighting is much harder to achieve. There's a wide range of different kinds, types and colors of light, and it's a complex task to create the correct light with the correct spot. To make matters worse, it has to be bright enough so other players can be spotted at virtually any distance (keep in mind that not everyone is forcing Gorge in a pink UTComp-dress). Don't forget to check out the light sources; lightless sources appear on even high-quality maps…
Sound effects are tough. Different variations and intonations can seriously boost the theme, but not much mappers devote a serious amount of time to them. On the other hand: not much players notice them either (some even completely turn off ambient sounds). Keep an ear out for how it's used, but there's no need to mention it if it's 'average' (Hourences puts it better than me: check this article). The same goes for music; certainly mention custom tracks and what you think of it, but there's no real need to describe the standard tracks once again...

Somewhere between AVA and gameplay are the "layout" and "framerate per second" subjects. These have to be addressed, but the question is in which paragraph. On Nali City, the aspects of FPS are usually discussed in both sections (BUILD and CAST), UP has it in the design section and Insite allows whatever the reviewer sees fit. Other reviewing sites may have different rules for them, so look up where to put these aspects of the map.

Beauty is in the eye of the beholder. In this case, it means that there is no true objective way to compare different maps. Deal with the map 'an sich', and where possible, with the aspects 'an sich'. What do you think of the chosen theme, and how would you say that the author managed to use the provided tools to create something beautifull out of the level? As a result, 2 maps can have the exact same score, while at the same time one of them looks more beautifull than the other one. And no, this is not 'just' when you compare a UT99 map with a UT2004 one; I know some UT maps that I've awarded higher visual scores than UT2004 ones, even though the latter ones looked better.

3.3 Gameplay: visuals are easy. You can write a perfectly good AVA section with nothing more than laying out the facts and providing a couple screenshots. Writing on gameplay is where discussions can arise, mainly because this is an abstract subject. Work by illustrations and comparisons to express yourself, or your writings will be hard to understand.
If you haven't sketched the layout before, do so now. When needed, you can combine this with item placement and/or flow. Good and bad points in relation to the gametype is also a good idea. In any case, keep an eye on the length of the layout: the more you tell about it, the harder players will be able to orient themselves based on your description.
Never forget about flow. Good flow can be recognized in the fact that there is no place more valuable than others, that players (bots, in your case) spread out seamlessly and that you'll never find yourself with a favorite spot, or a part in the map that you rarely - if ever - visit. I advise to mention z-axis somewhere in the area you're telling about the flow, as it's very important to check how the different floors are being used.

Then there is bot AI. To prevent any discussions: UT's Artificial Intelligence is smart compared against bots from other games, but rather dumb compared to humans (if you never noticed this, I don't think you're skilled or observant enough to be a good reviewer). There's a nifty command you can use to check a bot's jump possibilities: showjumpspots. It spawns a bot that tries to reach all its available jump spots. This can shed a more objective approach for bot observation, but don't bore your audience with the analytical errors when you haven't seen anything of it in a match. Another important thing is to check where bots visit regularly and what places they never go to (you'd be surprised how often bots completely leave interesting sections abandoned). Maybe it's personal, but when I'm spectating, everyone seems to play a lot dumber than when I'm fighting them. In any case, this is an illusion. Spectating can be a very usefull way to check what bots are doing, but it's in no way a replacement for an actual game.

3.4 conclusion: at this point, you have already told all the info, so it's time to draw the final conclusion. What do you think of the map? What stands out? To what kind of players (if any) would you recommend this map? Is there a final note you want to say to the mapper? Compared to the other paragraphs, this one is the easiest to write. It's important that your summary shouldn't contain new information. It's better to edit a previous chapter than giving a 'in addition to what I've said earlier, I haven't mentioned that...' line. It's the KISS-principle: Keep It Simple, Stupid.

Note: Insite reviews always have a bottom line. This is a single sentence that tells people what to expect from the map. It's displayed when people browse through maps, so make sure it has a correct index in this case. It's also used to commercialize the map because this sentence is what gamers read when they don't feel like reading.

3.5 proofreading: no, you're not there yet. However, you must always take a break between the previous step and this one. Go do something else for a while, and banish any prejudice on the map from your mind. When you get back, read your review carefully. Writing is like a slower form of speaking, and reading correspond to listening. If someone should read this text to you, are you able to comprehend what he or she is saying? Is it clear? To the point? Honest? Complete? Personally, I've made corrections in every single review I've made, so I can guarantee you this isn't a waste of time. Since nobody's perfect, make sure you've got a spelling checker enabled (you can find one at this site when needed). Oh, and as you can imagine, a lot of words that aren't in a dictionary are perfect (eg. 'mapper', 'replayability', 'okay-ish' and '1337').

3.6 scoring: both the easiest and hardest part of the review. For obvious reasons, it's always kept until the last part (don't even think of awarding a final score before your text is written!). Giving a good score becomes easier with every review, mainly because you've got more material for profound comparisons. Scores differ. Not just from person to person, but from site to site as well! Luckily, reviewing sites make their means to score public. The Insite review schema, the Nali city review schema and the Unreal Playground Reviewing Criteria are some good examples. IMO, strict criteria (like UP uses) are adviced when you just start out; it's even a good idea that instead of grading a map as a whole, you grade each subcategory and then use this excel file to calculate out the total score.
It's pretty normal to have a margin for error, even with everything said and done. At this point, you can use subjective elements for the final gradation (warning: keep this small. Certainly not more than 5% of the total score), like basing your judgment on what the mapper is capable of.

3.7 submitting: this is pure routine. Take a good look at the different pictures you've taken, and select the nicest looking among them (a good hint of advice: take more screenshot than you're going to submit, so you can pick some good-looking ones). the actual submitting differs from reviewing site to reviewing site. You will be informed about this once you're actually assigned a map to review :-)
Still, I urge you to keep a backup of your text+screenshots, at least until the review is safely posted. You never know what can happen...

Hints for style and content

There's no need for a smooth transition in subject between paragraphs; the readers will be so busy reading your stuff they probably wouldn't even notice it if the review was just an enumeration of aspects of the map
Always read the comments and critics that people reply on your review. Sure, a review is opinion, but it would be a darn shame if you were completely alone with that opinion
On Insite, a review is on its best when it contains between 600 and 800 words. More or less are allowed, but the amount of words is a good indication on how your review reads
Both on UP and on Insite, you can use HTML tags into your reviews. They can help to put the accent, but remember you're writing a text, not a graphical artwork. HTML tags are easy: <tag> begins a tag, </tag> ends it. Here are the only ones you'll need (you might wanna copy-paste that last one):
- these parts will be written cursive
- these parts will be bold
- this will be underlined
- <a class=adminlink href=www.somelink.com>this entire section will contain a link to www.somelink.com</a>
There are various ways to deal with a lack of inspiration. When everything else fails, you can always do a dry enumeration of what you discovered in the map. Routine can be a good thing, even when doing creative work, like writing...
Don't forget you're reviewing for a game: a whim of humor mixed in the text is always more fun to read than a regular review

Epilogue: bloopers by mappers