How do you counter BDD-scripting anti-pattern in Specflow?

This is an example of one of our acceptance tests:

Feature: Add an effect to a level
In order to create a configuration 
As a user
I want to be able to add开发者_高级运维 effects to a level

Scenario: Add a new valve effect to a level
Given I have created a level named LEVEL123 with description fooDescription
And I am on the configuration page
When I click LEVEL123 in the level tree
And I expand the panel named Editor Panel
And I click the Add Valve Effect button
And the popup named ASRAddVal appears
And I click the Add new button
And I fill in these vertical fields
     | field name  | value                |
     | Name        | Effect123            |
Then I should see the following texts on the screen
     | text                     |
     | Effect added : EFFECT123 |

We feel that this is getting a bit to verbose and we want to hear how you reduce steps in Specflow. From what I've read so far, creating specific non-reusable steps is not recommended, so what is considered "best practice" when doing this in SpecFlow?

Update:

What I am trying to say is that I've learned that you should try to create generic steps in order to re-use them across multiple tests. One way to do that is to parametrize your steps, for example: "Given I have created a level named ..", but the parameterization also introduces verbosity. I want to end up with something like Bryan Oakley suggests in his answer, but I just can't see how I can do that without creating steps which are very specific to each tests. This again means that I'll end up with a lot of steps which reduces maintainability. I looks like SpecFlow has some way of defining abbreviating steps by creating a file which inherits a base class called "Steps", but this still introduces new steps.

So to summarize things; show me a good approach for ending up with Bryan Oakleys answer which is maintainable.

I would simplify it to something like this:

Scenario: Add a new valve effect to a level
Given I have created a new level
When I add a new valve effect with the following values
     | field name  | value                |
     | Name        | Effect123            |
Then I should get an on-screen confirmation that says "Effect added: Effect123"

The way I approached the problem was to imagine that you are completely redesigning the user interface. Would the test still be usable? For example, the test should work even if there is no "Add" button in the redesign, or you no longer user a popup window.

You could try wording them generically and use parameters.

Given i have create a new: Level

the ':' is only so you can identify the parameter. This means you would have one generic entry point for a step that needs to create a new something. Its up to the step then to look at the parameter of Level and create a new Level

Also try to come up with a naming conversion everyone can use. It should be easy to discover what steps have already been created so you don't get duplicate similar steps.

Can I suggest that maybe the code you are testing should go into unit tests. Maybe what you mean by "test specific" are individual unit tests that are not covered by your acceptance tests.

Just a thought :)