When a developer decides to create a game they often begin with wanting to create an experience they themselves find interesting. The truth of the matter is, as I discussed in my article Children are Game Designer: how child’s play mirrors professional game development; developers are children at heart, seeking ways to express play, with the desire of sharing that experience with other people.
However, as with all creative endeavors, the finished product may end up being a far cry from the original concept. The process of game development is iterative and highly reliant on the designers’ capacity to embrace change, even if it means admitting when things don’t work and nurturing the elements of the game which have the potential for success.
All games begin with an intention:
- Within our game the player picks up a ball and attempts to toss it into a basket
- The challenge is that the basket is attached to a post that can be knocked over
- Knocking the post over resets the game and the player must start over
The developer creates the control system, the physics that will be applied to the ball and the stability of the post. They create a functioning win and lose condition system and the game plays as they intended.
Failure of core systems
Following the establishment of a functioning gameplay loop the developer must then test their design. However, the testing should be done by unbiased players. “Do the systems work as intended, is the objective easy to understand, are the mechanics accessible from the perspective of someone new to the game?”, etc.
Once a player, fresh to the game begins playing, things will break almost immediately:
- The player doesn’t understand that the focus is to land the ball in the basket, instead they throw the ball too hard and continuously knock the post over.
- Due to the physics within the game the post goes flying end over end, and the player becomes engaged in trying to send the post flying as far as possible with the most possible rotations.
The moment the designer witnesses their systems in action, how the player reacts to their mechanics, and what actually proves to be the fun part of the game, they must decide if they are willing to focus on what went right instead of what went wrong.
When players take systems originally intended for other uses and apply them in ways that make the game personally more fun, such as using the post as a target and making the objective how far they can knock the post over, this is known as emergent gameplay.
While it can be fulfilling to know that one’s systems work as intended and that the players appreciate and enjoy the design one wanted them to play, emergent gameplay points to the possibilities for gameplay which one may have been blind when focusing on creating one’s intended gameplay experience.
Commitment to change
Regardless of one’s original design, it is important to allow a game to grow to include and support the emergent gameplay that the systems inspire. The elements of design that players choose to play with the most must be viewed as accents within the original design intention, as opposed to simply breaks. Instead of being steadfast in one’s belief in their design, developers must be open to shifting the game towards what makes players want to pick up the game and play, since the end result must be an experience the players are interested in.
Have you ever worked on developing a game, even just working on a game to play as a child? What were the hurdles you faced when trying to make a game you envisioned versus one the players wanted to play? Do you believe it is important to view the game as a system that can change as you gain new information on how players view it? Or do you believe games should be worked on until their original design intention is fully realized? Or somewhere in the middle? I welcome discussion on this topic and if you have experiences of your own you wish to share please do so in the comments below, or write in to email@example.com.