No matter how hard you try, repetition is going to happen.
You need to figure out how to make the repetition fun.

To me, The most important principle of game design is fun.

what makes game x enjoyable? who will enjoy it the most? why will they enjoy it?

Games, like pretty much any other form of media and art, were made for enjoyment. They were made to be fun.

Some general goals you want from a game design:

* Promotes itself (attractive in words/pics/videos, social aspects so players get their friends in, user-generated content so people post it all over the internets for free publicity, etc)

* Provokes emotions (Details depend on game. If you sell your game as "makes you frustrated and hate the game", thats fine, and people will like it as long as it does what it claims to do)

* Does this effectively (quality)

* Does this for a reasonably long time (the game must either contain, or generate, interesting experiences over time, so its worth peoples money and to keep the community active)

* Does this for a reasonably large audience (familiarity to make it approachable, novelty to make it interesting, choice of platform)

* Does this for a reasonably low effort to implement (you want the design to be efficient. This is one reason why emergence is good, as its about patterns that you didnt have to manually build into the game.)

All of those overlap, and you always must make tradeoffs. Overall in game design, everything is interdependent, which is why iteration and other such 'dumb optimization' approaches are necessary (you cannot plan it upfront, because understanding it fully is too difficult). Of course, dumb optimization is dumb, which is why we should seek to understand as much as possible, so we can plan (efficient) more than we test (inefficient) to get the same result.

Now, those general goals would be how you evaluate the design at high level.

To evaluate the design, you apply your knowledge of human psychology (often relying on the assumption that "what I like = what others" like at first), as well as knowledge of the technical fields (ease of implemention) for the goals not related to player. So you can play it yourself, or imagine whether youd like to play it (or a similar game, to understand what effect the differences between the designs might have). But you can also get feedback from other people, do some proper playtesting, etc.

But you need something to evaluate first. Maybe you add something to existing designs and evaluate the result. Maybe you synthesise something original in your head and evaluate that (possibly after making a prototype to be more empirical about it). Then you can apply 'design fragments' that you think might contribute to enjoyable gameplay, to build up the complexity of your design (so you have larger possibility space to work with when trying to locate a particularly good design), which have something to do with following aspects of gameplay:

* Control (do you move a character? interact with things by shooting at them? give orders? tweak numbers? build something? activate things at right time? aim? what parts of the world can the player directly or indirectly interact with?)

* Structure (what primitive elements the game is built of, how theyre ordered. Structure is important for implementation efficiency, and player understanding. Pacing.)

* Physics (how do the elements interact, what rules they follow. How does the world change over time. How does it respond to player actions.)

* Valence (objectives, rewards, punishments, anything the player cares about, whether its formal like a 'points' system, or informal like having some cute animal people just care about)

* Communication (things that make the player learn, interpret, understand, feel)

And theres some common fragments, known good approaches, either because of momentum (its very easy to do what others do), or because player familiarity with those fragments (so theyre used BECAUSE theyre popular), for example:

-Being able to move a person (movement=control, what results from movement=physics, person=valence because people dont really care to act for inanimate objects)

-Getting points (valence, people like to get things)

-Click to shoot (control, physics for how the 'projectile' works)

-Zombie theme (valence, people care more about their survival when its against zombies, than against grey boxes, also communication, because people understand zombies are to be avoided)

-Map being divided into levels (structure)

-Having items you can pick up and do something with (structure, control, valence because players like to get things)

You find such fragments from everywhere, not just other games (any knowledge, pattern, system, behavior can be included in a game).

So, given a game, you could look at each aspect of gameplay separately, see what things affect that specific aspect, and then see how those things build toward the general goals of the design (to understand the design).

Going the other way, its a difficult problem. Its less like "finding the solution" and more like "finding any solution". So at first, a creative problem. Pick random things, see if you can think of a way to fit them together into something that works (Im not really going to think about 'how to be creative', doesnt really relate to games specifically).

Once you have found a starting point, you can get more systematic, start following rules/policies to extend your game following its structure and goals. Those rules/policies depend on what structure and goals you went with. For example, if you want every playable character to be equally good but also be different from other characters, thats a rule you can follow to produce extra characters.

Kind of like simulated annealing (at first relatively random sampling of possible solutions, then closer and closer examination/tweaking once you have a good general idea).

Any general rules will be directly related to the general goals (like adding nice coherent art/animation/effects because they create a more emotional experience, or introduce new things manually or through emergence at steady pace to keep the experience interesting over long time). There will also be more specific rules formed for any particular game or set of games/type of situations, that have been found to be relevant in the specific situation. You would think and explore those once you know the specific context (I guess a general rule would be to research what others did in a similar situation, whenever you have some design fragment you want to perfect, but thats just general design, not specific to games).

The general goals can be simplified as:

1. The game produces an experience that enough people want

2. The game does it efficiently and effectively enough

Something i haven't seen mentioned is Pacing and Complexity.

This isn't something I've read, but just noticed in good games. Pacing should be inversely related to complexity.

For example - sneaker-shooter games are slower paced than action-FPS games, but the good ones don't feel boring. That's because in addition to your health and ammo, you're also forced to account for visibility, noise, number of enemies, their patrols, etc.

The rising and lowering of intesnity is also an important part. You can have a super-intense gameplay style all of the time as long as there are occasional breaks in the action, or a slowly rising/lowering of intensity as the game progresses.

A good example of pacing vs complexity gone awry is late-game TBS or RTS games when you've conquered 50-60% of the world. Where before - 5-6 armies and 2-3 bases was easy enough to handle, now you've got 20-30 bases and 60 armies all swarming around the map. The more micro-managey the game is, the more difficult it becomes to handle all of it unless there are mechanisms built into the game to handle the issue.

If you've played the SystemShock/Bioshock series over the years, its slow evolution is a good example of complexity vs pacing decisions and its impact on gameplay, with the later games sacrificing complexity for increased pacing.

This is an intro class, right? And we're using game maker? OK. I would encourage the students to make whatever the hell they want because, hey, game design is just another form of art. Ultimately there are no rules. Encourage students to use their intuition and make whatever they feel like making. Just like with any artform, some students will be good at this and others won't. It is not in anyone's best interest to try coaxing unartistic individuals into artistic pursuits. Sink or swim. A game does not necessarily have to be fun. Maybe your student wants to portray the atrocities of the holocaust in an interactive immersion. Technically, this is a videogame she is making. Should her game be fun? When viewed in it's true aspect--that of an artform--game design has very few core principles which apply across the board, but a few do come to mind: 1.) balance. This is unfortunately hard to put into words as a skill and is yet another function of the designer's innate ability. It can, however, be described in abstract ways. Balance can be broad or narrow. Narrow balance means that competing forces are evenly matched and there is no clear advantage (the situation will change only narrowly and predictably). Broad balance means that competing forces are evenly matched, but severe advantage is still possible (i.e. A player may quickly obliterate his enemy with an atom bomb, but both players have equal access to it). This is only one description of balance, but you get the idea. 2.) immersion. The artwork must create the intended effect. This can be elaborated upon endlessly, but is pretty self-explanatory at its core. 3.) playability. The game must be playable. This is mainly a function of engineering, but has important artistic implications. The base functionality of the game's programming is one example of this, but a more artistic example is the artist's decision to forego displaying the character's health status in order to increase player immersion (the second core concept) by forcing the player to pay attention to other cues from the avatar (heavy breathing, limping, etc...) Balance. Immersion. Playability.

The ability to finish what you started (with strong focus on features prioritization, cutting non essential things, anti feature creep mindset, time management & deadlines).

you should probably make the distinction between design issues (pacing, balance, complexity, etc), and development issues (correct scope for the team size and time available, creeping featuritis, and similar production - as opposed to design - issues).

when bogged down in the trenches, its common for devs to blur this distinction as to what is a design issue and what is a development issue.

On 2016/5/6 at 6:09 PM, Dave Vin said:

I don't know about a specific principles of game design, but, I do have a bunch of sources that might help you compose your curriculum.

I'd suggest you check "Rules of Play- Game Design Fundementals"- if you want to go with a pretty theoretical route. (There's a PDF of it online).

Otherwise, you should check out these people:

-Game Maker's Toolkit

Unlike the name suggests, this channel isn't about Game-Maker, but about game design.

It has plenty of useful videos that are composed very well and really make you think about different games

and design ideas.

https://www.youtube.com/channel/UCqJ-Xo29CKyLTjn6z2XwYAw

 

-Extra Credits

 

You probably know these guys, but even if you don't, they feature a great bunch of videos about different game related topics,

such as narrative mechanics, how tutorials should be structured, and the hero's Journey (which is sort of a story structure).

Also their series "design club" might be useful to you.

 

-Errant Signal

https://www.youtube.com/user/Campster/featured

This is Errant Signal- and I'd suggest watching his more recent videos, rather then the ones he made 4 years ago-

since in my opinion his older videos lack experience and feel a bit like him reviewing art, if that makes any sense- (the ones from 4 years ago

but, he analyzes games in great detail and I find his videos to be highly educational and very interesting.

 

Overall, I'd strongly suggest you first check "Rules of Play" first and perhaps some of the other links in this reply later,

and I hope that this response has been of help to you.

Game Maker's Toolkit is so cool,man,thank you!