View Single Post
Career Officer
Join Date: Jun 2012
Posts: 709
# 49 Evil70th's Best Practices
06-24-2012, 10:50 PM
Hi folks,

I have been asked by several authors to put together some elements that I, as a reviewer of Foundry missions, consider to be ways to improve missions. So with the changeover of the forums to "Perfect World" and having to restart my "In-depth review" forum, I felt it was as good a time as any to put one together.

Over the past few months I've reviewed over 150 Foundry missions and have identified several items in many of the reports that needed to be worked on. This paper will summarize those items into, what I consider to be, a set of best practices for authoring missions Please remember, everything in this paper is only my opinion based on my experience, and they are yours to use of not as you choose.

Plots, storyline and dialogue:

The creation of a storyline is one of the most important elements of mission development. The author needs to capture the player's attention and then hold it for the length of the mission. Most players do not mind playing longer missions as long as there are elements to it that keep them engaged in the story.

Regardless of a mission being story or combat oriented it needs to have a plot to drive the action forward. In a combat mission if all the player does is flying into a system and battle large quantities of enemy mobs, then beams down to a planet, ship or a station to engage more enemy mobs with a single line of dialogue like, "Beam down sir" most likely the player will get bored quickly. This is true with a story oriented mission too. If a player spends time playing a story oriented mission and the plot makes no sense at all then you will lose them quickly as well. You have to have some plot to support the mission and it needs to make sense. Some things to consider when creating a plot for your mission:

  1. What is the motivation of the player to be in this mission? The mission is never as simple as "Fly in and kill the enemy". Then you put every type of enemy on the map. For me this would become tedious really quickly. That is not to say you cannot have multiple factions on a map but is there something to it. For example, there is a secret alliance between the Klingons and Romulans to destroy the Federation. If you don't explain that through even a short bit of dialogue the player will be lost and wonder why they should continue.

  2. What is the goal of the antagonist in the story? The enemy in the mission needs to have a goal. Are they here to wipe all sentient life forms in the universe? Why? There needs to be something driving the story forward.

  3. What is the goal of the protagonist in the story? The good guys need a goal that makes sense as well. If they are simply here with a secret agenda from Section 31 and they can't possibly share with the player. Then why play? There needs to be something to drive the story forward. By the way that was not intended as a dig at Section 31 missions. Okay, maybe just a little.

  4. What is the overall mission goal? Are we here once again to save the universe from another devastating enemy force, or are we finding the secret to an ancient civilization, and their technology. There has to be a point that brings the mission to a close and at the same time makes sense to the player. In the end it is up to the author to write a story, either combat or story oriented, that draws the player in and keeps them riveted to the seat in front of their computer.

The story dialogue that drives the mission forward is another element to good mission design. If the story dialogue does not make sense you will lose the player really quickly and your mission will become tedious. There is a simple way to avoid this. Read the dialogue out loud. This means to actually read the dialogue out loud while you sit in front of the screen testing the mission. When you read it to yourself your brain can trick you into thinking you actually said something in the dialogue that you knew was supposed to be there but actually is not. The brain is an amazing tool that helps us interpret the world around us. When we read something to ourselves and certain things are missing the brain will fill in the gaps by making assumptions. This is especially true if it is something you wrote, because you knew exactly what you wanted to say, even if you didn't write it like that.

Spelling and grammar errors:

As a general rule I will not lower my rating of a mission based solely on the spelling or grammatical errors, but it can be a contributing factor to a lower score. Many of the mission ratings I read, prior to playing a mission, mention "spelling" or "grammar" or both as an issue. Since that is the main thing they mention in their review on STO it would be logical to assume that accounts for a large part of the rating they've given the mission. In some cases it is a three star or less and others a four star rating. Yes even some are five stars with the accompanying "spelling" or "grammar" issues comment. The point here is spelling and grammar issues can easily be addressed with spelling/grammar checking available in most word processor programs on the market today. I write scripts for my missions using MS Word as my principle means of spell checking my dialogue. In the early days of my mission evaluation I noted a few spelling errors that, it did not occur to me at the time, were due to the differences in UK English and US English. I've done so many mission reviews at this point I hardly notice the difference anymore.

Map utilization:

This is an element of mission development that can be abused. To put it simply, just because you can create 10 maps does not mean you should. These are just a few things to consider when creating a map for your mission:

  1. Is this map really needed to tell the story? I have played a few missions where I am to rendezvous with an NPC on a planet, ship, or base. When I get to the entry point for the first custom map and I fly into the system, the spawn point places me half way across the map. The initial dialogue, if any, is one of my BOFF?s reporting we've arrived in the system and the NPC we are to meet with is waiting for us. I then fly all the way across the map, with nothing going on, to find another NPC with one or two lines that tell me to transport to the planet, ship or base. Then I am transferring maps again. This would be an example of poor map utilization. To fix this I would recommend the author delete the map and make the actual map where I rendezvous with the NPC the first custom map coming from a Cryptic map.

  2. Do the elements of this map support the story? This means have you placed the right elements on a given map, which includes dialogue, objects, and effects that will support the story. It does not mean you cannot have extra elements on a map for dressing just be sure they do not detract from the story you are trying to tell. In other words, you don't want the extras in the background stealing the scene from the star of the show. :smile:

  3. Can maps be combined and still tell the story? This means can you tell the story and combine the elements in one map. For example, you have a trip to a planetary system that you want to put into the story. You combine a space map with a warping effect. The player has a log they are reading or discussing the mission with their BOFFs as part of the story telling. At a certain point in the dialogue the player is prompted to drop out of warp and the planet that appears. This allows the author to include the elements of two maps into one and still tell their story. This would also free up another map space in the mission for your story if you really need it.

Triggers, effects, and NPC utilization:

Using triggers to tell a story is another important skill to have when developing a mission in the Foundry. Here are a couple of ways they can help:

  1. I have recently learned how to use objects to trigger optional dialogue on a map vice NPC's. This allows the author to add a sub-plot or supporting dialogue that may not be required to complete the map but adds to the overall story. It also gives the author the ability to make the dialogue go away after the player has interacted with it. This is not the case when an author uses the standard NPC to trigger optional dialogue. I've played missions where I spawn on a ground map and there are several information icons "I" all over the map. Only one is really important to the story and required to finish the map but now I have to sift through them all. Then all the optional dialogue NPC says is a one liner about how busy they are and tells the player not to bother them. It has nothing to do with the story and is very annoying. The player spends 20 minutes trying to find the NPC they have to talk with in order to continue the mission. The short version of this would be try the trigger objects for optional dialogue. It works great.

  2. Triggers can also be used to activate effects, trigger enemy mobs, open doors or even set up new options. It is a way of having branching story dialogue on an individual map and allows the author to tell a more in-depth story if the player seeks it out. An example of this would be in my mission "Contamination" I have an option that pops up on a map where the player can trigger an anesthetic gas that knocks out the enemy giving the player the option to avoid combat. If they choose not to do that before reaching another trigger point on the map the option goes away. I use this for optional dialogue as well on virtually all the maps I designed for that mission. It is a good work around for the linear nature of the storyline in the Foundry albeit only for each map and will not affect the overall storyline. However if the story is well written the player will never notice that.

Using effects to dress up a story is another important skill to have when developing a mission in the Foundry. Here are a few things to consider:

  1. There is no point in adding an effect that the player never sees. For example, you set a warp core to breach on a ship and then beam to your ship to trigger it, but the spawn point faces away from the explosion. In that same example the ship must move to a safe distance before detonating an explosion. They move away and the explosion goes off while they are facing away. So then the question is, why bother adding the actual effect? You want to showcase the effects as part of the story, so you have the spawn point facing the blast. Then when the player triggers the explosion they get to see the boom.
  2. The opposite of this would be having effects that overwhelm the story or other map features. In the "Map Utilization" section above I mentioned "extras in the background stealing the scene from the star", this would apply to effects too. I've played missions where the author designed a beautiful map and filled it with a great story. It took me 20 minutes to find anything because the author had it filled with NPC triggered optional dialogue and a heavy dust storm so I could not see anything until I was right on top of it. Now that is very tedious. That doesn't mean you shouldn't use the dust storm effect, but be careful how you use it. Does it really do anything for the story? If not, then why have it?

  3. Some of the effects do not work exactly as the DEV?s intended. What the heck does that mean? It means that some of the effects were designed to work in certain situations but not in others. In some cases the effects are just plain broken. When you find those elements you should provide a detailed report to the DEV's so they can fix it. It may not get fixed right away but it will get there eventually, and they can't fix it if they don't know it's broke. This was true for some of the space explosions when the Foundry first opened for use. Now they work pretty well.

  4. The utilization of NPC is another issue that can be easily overlooked by an author. The difference between NPC's and NPC groups is the individual NPC's in the groups will default to the name of the character. For example a Klingon warrior will be labeled "Warrior" or a Starfleet tactical officer will be labeled "Tactical Officer" or something along those lines. With NPC's if they are not given a specific name they show up on the map as "UGC Contact", which can detract from your story. The point here is that if you place NPC's on a map as background you should name them, even if it is simply copying the designation to the name field.

Testing your mission:

There have been a number of times when I mention to the author "I cannot find a story element" or "the element doesn't work" in their mission. The normal response I get back is "It worked great when I tested it" or "I had no problem with it". Here are few things the author needs to remember:

  1. Just because it worked during testing in the Foundry doesn't mean it will during regular play. The only way to be sure is to test it in live play on the server. When I do this I put something in the description regarding "Testing, please do not play" or something along those lines. That will not prevent idiots from picking up your mission and rating it because, as I said, they are idiots, but it will give you a chance to test if it works in live play.

  2. You should also remember that just because you are able to find the story point, interaction, trigger, or other mission objective on a map does not mean the player will be able to. Take into consideration that you designed a mission and of course you know right where everything is and how to get to it. The player will not have that advantage unless you give them clues through dialogue or other mission elements that point them in the right direction. This would also apply to mission length. For you the mission may only take 15 minutes to complete, but for a player it takes an hour because they do not know instinctively where everything is.

The use of response buttons:

When I refer to response buttons I mean the buttons at the bottom of the dialogue window. I know you might have thought that based on my mission reviews this would be at the top of the list. While I do feel it is important, it is not as important as the other items discussed above. As most anyone who has read just about any of my mission reviews knows the use of the response button "Continue" is a pet peeve of mine. There are occasions where it works although I encourage authors to use alternatives to it. For example "..." vice "Continue". Part of this is because I want the author to consider what response is appropriate to the dialogue. As all authors should be aware "Continue" is the default if you leave the button blank. Why does this matter? In my opinion it detracts from your story. For example, one of the player?s BOFF?s says "Captain, there is a Klingon Bird of Prey decloaking off the port bow" the play?s response is "Continue". It just doesn?t seem to fit the dialogue.

In the end it is up to the author how they want to use these response buttons to drive the story forward. Remember you can also put the players response in the dialogue window as well, you just have to make it stand out from the other dialogue. Using either [OCC] or [MissionInfo] dialogue is the best way to make it stand out. I prefer the [OOC] myself when designing more extensive responses from the player.


It's the details that will get you every single time. I think everyone who has ever had a mission reviewed by me knows I do in-depth but fair reports on authors missions. I have tried to capture those elements that are what I consider to be "Best Practices" in this paper. The above items are ways I feel missions can be improved by the authors. By improving your missions you in turn improve the community and the quality of play for everyone. This makes the entire STO experience a much deeper and rich experience for all players. I reserve the right to edit anything in this paper without notice.

Thanks for reading,
If you would like a detailed review of your mission please visit my forum posting "In depth mission reports upon request" for details.

Last edited by evil70th; 09-07-2013 at 07:09 AM.