How to use

The subtitles above should give a good idea of how to use the program, but you can also learn from the example (press load) or read below for more detail.

EMOTION

An EMOTION is a state of mind, reaction or "thought" that occurs to the player. It could be something typical like "skill mastery" as is seen in puzzle games, platformers, FPSs and so on, or "anticipation" as is seen in story based games and adventure games. It could also be a thought or state of mind, such as "I should avoid the color blue" or "I need to figure out what's going on here". These will be the core reactions players will have in your game.

ACTIVITY

ACTIVITIES are behaviors of the player or things the player does, such as "solving puzzles" or "fighting enemies". It is very important; if some activity is the main thing you do in the game but it doesn't contribute to your intended EMOTION / doesn't increase enjoyment, you have a big problem. List only the ACTIVITIES in which the EMOTION would occur as a result of taking part, and any ACTIVITIES that don't fit within an EMOTION should be discarded. These activities must be enjoyable in some way for the game to be enjoyable. If "managing your inventory" is not fun, discard it until you can make it fun.

DESIGN

DESIGNS are facts about the game which will enable and encourage the above ACTIVITY, and in doing so encourage its EMOTION response. There are two main types of DESIGN statement; 1) some feature exists, therefore players will have a reason to take part in ACTIVITY, 2) feature exists and that's why that activity will result in EMOTION. For example in a horror game, we could say "running from enemies" is the activity, but that's not necessarily going to result in a fear response, since you run from enemies in plenty of not-at-all-scary games. So we could have "enemies only appear sometimes" and "the player has no way to fight back" and "there are places you can hide from the enemy" and now you have a horror game. It is best not to rely too much on these "this is why it will have this effect" statements however, since if the player doesn't do the ACTIVITY, then you wasted your time designing it.

Who invented it?

Sumi (sumianvoice) c. 2020. Initially it was called EAMD with M being mechanics. I removed the mechanic part since it was redundant; mechanics are just necessary code systems that you have to make in order to implement the game, not design it.

Previously for many years I used another system I created called CAPR; Challenge, Accessibility, Progress and Replayability. This system was geared towards dopamine tredmills. It was quite effective too, but for a type of game I don't care for anymore.

Good luck on your games!
- Sumi