What's good implementation?

This thought came when I was working on my first serious parser game.
What is considered “good implementation”? What makes a game well implemented? What makes a game poorly implemented?

I thought that implementation was having as many actions/synonyms /adjectives for objects and the world as possible. But I feel there’s more to it than that.

So, I would like to know what you guys consider as good implementation and bad implementation. some examples would also be nice.

3 Likes

The best set of examples is David Fisher’s IF Gems (http://davidfisher.info/if/gems/) which is collected from IFComp reviews. As you can see, there are a lot of aspects to game design! Which of those count specifically as implementation is up for debate.

5 Likes

“Good implementation” is a bunch of conventions that parser fans agreed to in the mid-90s, probably. Not in any formal way; it was just a lot of “here’s what the games we admire do”.

The two principles are basically:

  • The player should spend their time figuring out what to do, not figuring out how to make the parser understand what they want to do. This means extra synonyms, as you said, but also making sure that most actions can be couched in common IF verbs.
  • The game should generate output that reads well in every situation. That means extra narrative variations as the game state changes. Don’t describe something as a “surprise” every time the player looks at it, etc.

Plus, you know, lots of testing and fix all the bugs.

7 Likes