Game mechanics design process

From Post-Apocalyptic RPG wiki

Jump to: navigation, search

Established workflow.png This article covers an established workflow.

Established workflows have been discussed among and agreed upon by the development department(s). They should serve as documentation how these workflows are successfully utilized in the project.


This article covers the whole game mechanics design process. First it gives a basic introduction to the philosophy that should be applied when designing game mechanics for PARPG. Furthermore it explains how new mechanics are designed from scratch and how existing mechanics are improved. This article does not explain the basics of game mechanics design. It rather assumes that you're already familiar with game design and therefore just explains how to apply your game design knowledge to PARPG.

Contents

Mechanics design philosophy

When we started working on the mechanics for PARPG, we didn't have a really clear idea of what they should be. Many cRPG games just rip their mechanics directly from a Pen-and-Paper (PnP) game, or use highly derivative rules. They may add a little detailey "chrome" to take advantage of the computer, but with a few alterations they could be played as PnP mechanics. This was sort of what we thought we were going to do - pick and choose mechanics from my favorite PnP games and fit them to our vision of the PARPG setting. For the record, we are most "inspired" by the following PnP systems: GURPS, Hero (Champions), Aftermath!, RuneQuest/Call of Cthulhu.

Then a funny thing happened. The seeds of this were planted when one of us read Design Patterns of Successful RPGs. This is a generalized description of all types of PnP RPGs - including the "simulationist" ones credited above. All (?) Computer RPGs are essentially simulationist - as opposed to more "story telling games. We were basically "reconciling" the mechanics of the above games when we realized that the various details and abstractions made in these games ARE NOT NECESSARILY RELEVANT to a game played on the computer. For example, some games use d6, some d20, some tables, etc. etc. The computer doesn't care - it's all (eventually) Op codes. But real people do care about how many dice they roll, and how much effort it takes to resolve things in real time. But a computer can do 1000's of chained "die rolls" and table look ups PER SECOND. The 'human interface use cases' between computer RPGs and PnP games essentially do not overlap at all!

So then we got general. What do players (and their avatars, the PCs... and NPCs) DO in the game. And we started working backwords... and this set of linked pages is where we are so far. The key design feature of these mechanics is that they will be (at first) general - but tunable as to game "difficulty" or "cinematic level". This allows us to define game mechanics and then "balance" them post-facto.

How to design new game mechanics

Brainstorming and feedback

Pretty much every creative process in PARPG starts with initial brainstorming and feedback by community and developers! That's the case for the game mechanics design process as well. So hit the IRC channel or the forums and introduce your game mechanic proposal there. The other developers will usually ask a couple of questions and might raise concerns. Don't take offence in that; it's nothing personal. They simply want to help you create a great, well-designed game mechanic. So take their feedback into account.

Research the topic

Before you jump the gun and create a new wiki article for the game mechanic you have in mind, take a step back and do some essential research first. First of all you should find out if somebody else has already started to flesh out the same or a pretty similar mechanic. The best way to find out if a similar mechanic has been already submitted, is to take a look at the Game mechanics article.

The game mechanics there are categorized by their level of maturity. While some are heavy work in progress and mere stubs at this point, others have been already reviewed and approved by the team or even have been already implemented into the game.

If you actually want to design a game mechanic that improves an alrighty approved or implemented mechanics, follow this guide. Make sure to check if there are any Work in progress game mechanics that are similar to the one you want to introduce. If so, take a closer look a them to see if one or more of them would actually form a useful fundament for your mechanic.

To simplify matters we assume that no competing fleshed out proposal resides at the mechanics section.

Learn how to edit the wiki

As all game mechanics reside at the wiki, you will need basic wiki editing skills for the task at hand. While wiki editing is pretty intuitive, there are some basic tricks you should be familar with. The best starting points are these two articles:

Make sure to read through them and apply the learned lessons when working on your mechanics article. The other developers will sooner or later take a look at your article so make sure you apply proper structuring and markup.

Game mechanics structure

Every game mechanics article should contain these basic sections:

Categorization
New mechanics are categorized as work in progress until they're ready for review. To do so, add {{WIP game mechanic}} at the top of your new article. This will add your game mechanic to the work in progress mechanics category.
Summarization
Describe the essence of the mechanic in one or two short, descriptive sentences. Don't start a game design rant here.
Table of contents
Don't worry about this one. The wiki software will automatically generate a table of contents if necessary.
Design philosophy (optional)
In case you actually want to elaborate on your design philosophy in detail, here is your chance. Name the games and designers that influenced this specific mechanic. Make sure to keep all design philosophy talk in this specific section of the article. Design philosphy (the: Why?) and the actual game mechanic (the: How?) should NOT be mixed!
Game mechanic
Describe the game mechanic in detail. Make sure to be descriptive; this will ease implementation later. Don't write in first person style, these rants are reserved for the design philosophy section!

Flesh it out in detail

Once you have the basic structure for the article in place, you can go on a design spree and flesh out the article in detail. At this point you can pretty much apply your game design knowledge. It's a good idea to ask for feedback from the other developers while working on the article. Hint: as the programmers will be implementing the mechanics into the game in the end, it's a good idea to get their feedback as well! They'll be mostly looking if the mechanics are actually descriptive and therefore easy to grok and implement for them.

Request review

Once you're satisfied with the shape and content of your game mechanics article, it's ready to be reviewed. To give the other developers a pointer that your mechanic is ready, replace the {{WIP game mechanic}} section at the top of your article with {{Submitted game mechanic}}. This way your mechanic will show up in the list of fleshed out mechanics that are awaiting review.

Mechanics gets usually reviewed by the other developers of the department and key developers of the other departments. The programmers will implement the mechanics in the end, the graphics artists will have to worry how to visualize them, the writers will apply the mechanics when designing new quests. That also means that each department has a natural interest that the designed mechanic is actually easy to understand despite possible complexity of it. That's why clarity trumphs when writing down the mechanics.

The same rules that apply to feedback do apply to the review process as well: don't take it personally! If you have requested feedback early and revised your mechanic based on it, that's pretty much a guarantee that there won't be any objections against the mechanic per se. There might be some minor requests to clarify or reformat a certain section of the article, but that's pretty much it. After the article has been revised based on the review, it gets tagged as accepted game mechanic by replacing the {{Submitted game mechanic}} section with {{Accepted game mechanic}}.

Lobby for implementation

Now that your mechanic has been reviewed and approved by the other developers, it's awaiting implementation. The decision which mechanic to implement next is a pragmatic one. That means that the leads of all departments will sit together, take a look at the list of accepted mechanics and will decide which one makes the most sense to implement next.

This said: it doesn't hurt to bring your specific mechanic to the attention of the other developers. Be aware that this is a pretty thin line: everyone appreciates a pointer but make sure you don't come across as a pain in the neck.

How to improve existing game mechanics

Existing game mechanics are hereby defined as mechanics that have been either already reviewed and approved for implementation by the developers, or game mechanics that have been actually already implemented into the game.

Fixme.png Please help FIXME!
Personal tools