|
Guidelines
and Policies for Review Writing
We will consider any review
sent to us for publication on the web. We're not fascists and
aren't trying to force people to do things "our way".
Still, we do reserve the right to reject reviews that fail to
live up to some basic guidelines.
#1: WHAT
MAKES A GOOD REVIEW? We
want to see evidence that you have:
- Spent some time with the
scenario before rating it
- Thought about why some
approaches that have been taken in the scenario were used
- Relayed your views and
backed them up with argument
We suggest that you imagine
that you are the scenario developer and ask yourself "Is
this review of any use to me? How does it help me? Are the views
valid - why or why not?"
Remember, someone has probably put weeks if not months into developing
such a scenario. If it's bad, say why and what can be done. If
it's good, say why and identify what can be learned from it for
other developers to note.
#2: WHAT
TO REVIEW: A list of scenarios
that we recommend for review is prepared each week by El Khan
and posted on our download page. We encourage you to review scenarios
from this list to facilitate discussion and provide timely feedback
to those who have requested it. Other people may request reviews
on the message boards.
Freelance
Review Policy: "Freelance"
reviews of scenarios not on the suggested list are also allowed.
You may review any scenario available on the internet provided
that you did not write it yourself.
#3: THERE
ARE NO LENGTH RESTRICTIONS:
There is no set length limit for reviews, but we prefer that
they be long enough to provide specific criticisms. Reviews that
simply rate a scenario without providing specific areas that
could be improved and suggestions for improvement will be rejected.
#4: GO BEYOND
THE OBVIOUS: Our main concern
with many current reviews is that they seem too superficial.
A lot of reviews have taken the form of saying, "I liked
this, I didn't like that". We need to move to a higher level
and provide reasons for why we liked/disliked something and ways
to improve on it.
#5: CONSTRUCTIVE
CRITICISM: All reviews
should provide constructive criticism. That is, you should recommend
specific things that you personally would change if you had unlimited
time to modify the scenario yourself. For example, it is not
enough to write, "The readme stinks". You should specify
the things you would change. For example, you might say, "The
readme would be improved by including a list of Wonders, as well
as unit stats. I also wondered what sources the author drew on
when designing the scenario, as historical accuracy was good."
Really
Bad Scenarios: Some scenarios
are just really bad. In this case, you may need to suggest things
that most scenario designers know. For example, you might suggest
using a custom units.gif file and suggest some specific units
that would be good to include.
Wording
Choices: There are nice
ways to say things and there are not-so-nice ways to say them.
While we think everyone here is mature enough to accept criticism
in the spirit it was intended, there are ways to sugar-coat your
review a bit to make it sound less harsh. Some useful phrases:
- "It would be better
if..."
- "The scenario could
be improved by..."
#6: LEON
MARRICK'S "SEVEN SIGNS":
At the very least, the following problems should always be flagged
and mentioned in reviews. These are taken straight from Leon's
document, "Advanced Scenario Design".
1. A non-functional
scenario. The uploaded
.zip file may be corrupt, or the Rules.txt file may have fatal
errors. After zipping your scenario for submission, unzip it,
install it exactly as your instructions say, and make certain
it works.
2. A garbled
readme or scenario briefing.
Nobody has any excuse for not spell-checking his work, or for
not making certain his audience knows what the scenario is. Those
writing documents in a second language had better make QUITE
certain they are comprehensible.
3. A map
mostly consisting of grassland.
Clear evidence of lazy cartography. Their efforts to plop down
patches of woods, hills, plains, etc. merely amuse. Make very
certain your geography makes the game either realistic (in historical
scenarios), faithful (fantasy scenarios based on another's work),
or amusing/fun/replayable (in your own imaginary realms).
4. By-guess-and-by-God
terrain alterations. I
have seen mighty cities with wilderness hinterlands, cities with
no water supply or irrigation, irrigation on swamps, mining in
grasslands, city radii completely railroaded surrounded by utter
wilderness, ... And so on. The terrain alterations each civilization
is granted in your scenario says a lot about the economy of that
culture. Properly used, you can recreate a living society for
the amusement of your audience.
5. Misspelled
city names. Some people
use an atlas in their native tongue when naming cities. This
is good, especially in scenarios with protagonists speaking that
language (There is a Catalan scenario that benefits greatly from
this.). Others, whose own language may not be English, use English
to attract a wider audience. This, too, is good, although extreme
care is required. Some people can't seem to decide which language
they are using. This is pathetic. Check out an atlas, and get
a dictionary.
6. No or
inappropriate scenario limitations.
I have suffered through scenarios that claimed to depict the
Cuban Missile Crisis, only to get 10,000 Cubans on Alpha Centauri,
scenarios based on the Pacific War that ended up with Zulus controlling
Polynesia (when Tokyo fell, the empire split), and scenarios
covering the establishment of the Roman Empire fought out with
destroyers. Eliminate all ridiculous situations, except those
you plan.
7. Cities
that riot, starve, sell off structures, etc. during the first
turn. Make certain your
players start out with working civilizations (unless you specifically
warn them to expect otherwise). Always design in Deity level
(and change at the last moment if desired).
If you have any questions
or comments, post a message in the Apolyton Community Forum.
Someone will be glad to help! |
