User:TheJoebro64/How to write a dope video game article
This is an essay. It contains the advice or opinions of one or more Wikipedia contributors. This page is not an encyclopedia article, nor is it one of Wikipedia's policies or guidelines, as it has not been thoroughly vetted by the community. Some essays represent widespread norms; others only represent minority viewpoints. |
So you want to write a dope video game article. Great! But you don't know where to start, how to structure it, how to even write it, etc., and you've just happened to stumble upon this essay. Now, allow me (TheJoebro64) to guide you on how to write a dope video game article!
Step 1: Making sure it's notable
[edit]Note: sometimes you will skip this step.
If the page is either A: unsourced, B: a redirect, or C: doesn't exist at all, you must first make sure it meets the general notability guideline (GNG). To determine if it meets the GNG, try this:
- Search for it in Google Search or Bing. Does anything besides GameFAQs, GameStop, or Best Buy show up? And if so, is it a reliable source (RS) like IGN, perhaps GameSpot? Or is it Seymour Phillips' Lit Wordpress Blog?
- If nothing immediately shows up there, try WP:VG's custom Google search engine. This will not only ease finding RSes, but help you find some pretty obscure foreign language sites that could help.
- If both 1 and 2 prove to be a pain in the ass finding sources, look for print sources. This may be hard, but some online databases such as Sonic Retro and MobyGames have libraries of old magazine scans, and Amazon or Google might have a couple of reliable books about your subject.
- If you don't turn up with any RSes, then bam, it's not notable. But fear not, this will (likely) happen very infrequently.
Step 2: Game plan
[edit]Now that you've got your sources, start to plan out how you'll write the article. High-quality articles usually follow this format:
- Lead: a basic summary of the article. Try to keep the lead brief, but make sure it will heighten the reader's interest and make them want to finish reading the article. The lead's weight should be proportional to the article. For example, Batman: Arkham Asylum's lead is four paragraphs, while Sonic Rush's is only two. Normally, leads should be structured:
- First: title, year of release, story, gameplay.
- Second: Development (how they made the game), a more detailed release schedule (e.g. it was released in Japan in April 1987, followed by America in June 1988), and, if deemed necessary, promotion.
- Third, reception (pre- and post-release), sales, awards (if any)
- Fourth, legacy (impact the game had). Keep in mind that not every article is going to have enough content for four paragraphs, and some may only have enough for two.
- Gameplay: should illustrate, well, how the game plays. This section is easy if you've played the game, but can be hard if you haven't. I strongly recommend playing the game before you actually write the gameplay section because it is far easier to describe when you've got a firm idea of how it plays.
- Plot: what the game is about. This should only be in the article if it's really important; if it's not, merge it to gameplay.
- Unlike the other sections (besides the lead), plot sections do not need sources. However, if sources covered the plot in adequate detail (or the game is rare, so other editors keep adding an "unsourced" banner to the section), go ahead and add sources to it.
- Development: how and why they made the game. This part is the most interesting to write but can also be the hardest to find sources.
- Release: a section that details the promotional campaign for the game, and provides a release schedule. Sometimes, the release section is small enough to be grouped in the development section. However, promotion and release is distinct from the game development process 99% of the time, so it's best to keep it separate.
- Reception: what critics thought about the game. It's the polar opposite to the development section: it's easiest to find sources for, but unimaginably hard and boring to write. I've actually abandoned multiple draft articles I made because their reception sections—no matter what I did—would always come out looking like horse shit.
- Legacy: the impact the game's had (did it innovate the genre? Did it introduce new charatcers? Did people call it one of the best/worst? Did it spawn memes that gained coverage by third party reliable sources?)
Step 3: Actually writing the article
[edit]Alrighty, time to write the article. There are two ways you can handle this:
- Edit in mainspace.
- Edit in draftspace.
I personally prefer editing in a draftspace (I've got a ton of them at User:TheJoebro64/drafts): you're less likely to get in an edit war, thus giving you more freedom in making the page. However, if the page is already in decent (or half-decent) shape, don't be afraid to be bold and edit the article. The most ideal way to write an article is not by following the format of the article, but this way:[a]
- Reception: the hardest section should be written first, in my opinion. Actually, it's pretty healthy to write this first, since you'll have most of your references in the article when you're done. Anyway, tips for this section:
- Don't feel obligated to saying the reviewer's names; you can just say the publications if you'd like.
- Group similar statements together. Try making the reception section at least a couple of paragraphs, and each paragraph should have a different point. Knuckles' Chaotix is a good example of this.
- Avoid the ill-fated "A said B" format for writing reception sections. This is repetitive, looks ugly and lazy, and also doesn't tell you much. Good reception section: Donkey Kong 64. Bad reception section: Super Mario 3D World.
- See this essay by czar and Mike Christie. This is a really good guide to making your reception section a nice read.
- Gameplay: this should come after reception, since the sources in reception are also the sources you'll use in gameplay. Some pointers:
- Avoid using jargon like "energy packet" or "gameplay mechanic". If you use terms like these, explain them.
- Don't say what button does what, what combo does what, etc. Wikipedia is not a substitute for the game's instruction manual. Example: instead of saying Sonic can jump if the player presses A or B and spin dash with Y, say Sonic can run, jump, and spin dash.
- Sometimes, the official strategy guide and/or the game's instruction manual can be useful. However, try not to overuse these, as they are primary sources.
- Make sure there's a screenshot (a picture of the game) to illustrate gameplay.
- If you've never played the game, do this: either paraphrase from reviewers, or look up gameplay videos to get a basic sense of the game.
- Plot: just the story of the game. Nothing major here, just keep it proportional to its importance in the game.
- Development: how they made the game. You might be tempted to write this first, but don't. Save the best for last. Here are some tips:
- Look for interviews with key development personnel. The official strategy guides sometimes have interviews with those who were involved with the game.
- Magazines such as Retro Gamer and GamesTM often have "making of" features. These are extremely useful. Some editors collect issues of these magazines and will upload scans for you if you ask them.
- Find preview articles from shows like the Electronic Entertainment Expo (E3); the writer will often detail how the developer made something.
- Release: a documentation of the release schedule/promotion:
- IGN, Nintendo Life, GameRankings, and other RSes often provide accurate release dates, and cover the promotional methods used.
- Avoid GameFAQs, wikis (Bulbapedia, Super Mario Wiki, etc.) or other user-generated websites.
- Lead: now that you've written the article, write the lead. See the pointers in step 2 as to how to structure this.
Step 4: Impress readers and other editors
[edit]You've written the article, now everyone can see it! If you feel really good about it, you can nominate it for good article status, and maybe one day, featured article status.
Notes
[edit]- ^ I hardly ever actually do it this way, but it is useful