#10 - The Art of Game Design - Chapters 10,11,12

Chapter 10: Some Elements are Game Mechanics

Let's begin with a definition on what Game Mechanics are.  But therein we have the problem - there is no clear concise, standard definition.  To me, game mechanics are the inner workings of a game, but Jesse Schell categorizes game mechanics broadly by expanding mechanics to include not only the interior mechanics but also aspects such as rules, objectives, and more.  This culminates in quite a number of lenses:

Lens #21: The Lens of Functional Space.  Consider the dimensions and physics of game world itself - the space where entities in the game exist within.
Lens #22: The Lens of Dynamic State. Consider the entities that inhabit the game world as being in "states".  What knowledge can/do they know and what actions can they perform?
Lens #23: The Lens of Emergence.  Outline the actions of the entities in the game world, and consider the consequences of such actions.
Lens #24: The Lens of Action.  Consider a subset of actions which are important to achieving goals and impacting behavior of other entities, and the relative size of such a subset.
Lens #25: The Lens of Goals.  Consider goals in the game, short-term and long-term, achievements, and the plausibility of them.
Lens #26: The Lens of Rules: Describe the rules in  your games.  
Lens #27: The Lens of Skill: Consider the skill required to play the game, and win it.  Design for challenge and fun; a flow state between anxiety and boredom.
Lens #28: The Lens of Expected Value.  Consider the odds of random events in the game, and assign values to each.  The expected value (rewards) are often valuable to examine.
Lens #29: The Lens of Chance.  Examine what in your game is chance.  Is it too random?  Too much chaos is never a good thing; but perceived control within chaos is.

Chapter 11: Game Mechanics must be in Balance

Game mechanics as described in chapter 10 above must be in balance.  This means that no particular player in a game has an unfair advantage over the other.  There are several facets to this, which are further explored in the following lenses:

Lens #30: The Lens of Fairness.  Consider fairness from the viewpoint of every possible player.
Lens #31: The Lens of Challenge.  Similar to lens #27; consider the challenge level of a game, which should be between anxiety and boredom, in an optimal "flow state".
Lens #32: The Lens of Meaningful Choices.  When a player makes a choice in the game, they should feel as if it mattered, without it being a dominant choice in itself (not a "gimme".)
Lens #33: The Lens of Triangularity.  "Triangularity" refers to a set of states of the player, in which going to one state is "playing it safe", while the other is "taking a risk for higher reward".  We are concerned if we have such a preferred mechanism in the game, and if it is in balance (i.e. a hard choice to make.)
Lens #34: The Lens of Skill vs. Chance.  Consider the balance between skill and chance in the game.  Similar to lens #29.
Lens #35: The Lens of Head and Hands.  Consider the balance between physical skill and mental skill, and be sure they match the targeted audience's preferences.
Lens #36: The Lens of Competition.  Consider the level of competition in the game from across all levels of skill.  Who can play?  Is it easy to become a master?
Lens #37: The Lens of Cooperation.  Is cooperation required and is communication readily available?  Consider social aspects in the interaction, and whether its between strangers or friends.
Lens #38: The Lens of Competition vs. Cooperation.  Consider the balance between the two, and the preference of the audience.
Lens #39: The Lens of Time.  Consider how long a game takes, and whether it can be played that long without going bored.
Lens #40: The Lens of Reward.  Do rewards make sense and are they plenty enough?
Lens #41: The Lens of Punishment.  Do punishments make sense and are they plenty enough?
Lens #42: The Lens of Simplicity/Complexity.  Consider the level of complexity in the game, and of all its individual mechanics.  Too complex is bad, but so is too simple.
Lens #43: The Lens of Elegance.  Is the game elegant?  And all of its individual elements?  Elegance can make a game a masterpiece.  Make sure all elements of the game are useful and have a purpose.
Lens #44: The Lens of Character.  Character is the opposite of elegance.  Consider the character of the game, including its flaws and humorous aspects.
Lens #45: The Lens of Imagination.  Imagination can help a player immerse into the game world.  Consider how to inspire imagination in the game.
Lens #46: The Lens of Economy.  Consider the game economy, and game money, and prices of items within - and the balance of each therein.
Lens #47: The Lens of Balance.  Culminating chapter 11 all into a single lens - is the game balanced?

Chapter 12: Game Mechanics Support Puzzles

Considering puzzles in a game, there are a few guidelines outlined in these lenses below:

Lens #48: The Lens of Accessibility.  Visualization of the puzzle must be accessible, and the player should have a rough idea of how to "dive in" and begin.
Lens #49: The Lens of Visible Progress.  Progress should be visible as it is being achieved, as well as meaningful.  
Lens #50: The Lens of Parallelism.  Parallelism refers to making multiple puzzles available at once.  However, too many things at once may not be very good.  Consider bottlenecks in which completion of earlier puzzles can constrain advancement of the game, and the connectivity of such tasks.
Lens #51: The Lens of the Pyramid.  Pyramids apparently fascinate us, because they have a single point at the top which seems to be the culmination of lower layers.  Consider building the game up in this manner.
Lens #52: The Lens of the Puzzle.  Consider puzzles in the game that make the player think, and each of the puzzle principles outlined in chapter 12.

#9 - Hansel & Gretel: Witch Hunters (Film, 2013)

Summary: Hinged upon a mysterious past in which siblings Hansel and Gretel lose their parents in an unknown way, the siblings have grown up with quite a reputation for slaying witches, beginning with their rise to fame as kids when they burn the witch within the candy house.  When summoned to a local village to accept a contract and rescue the witch-napped children, Hansel and Gretel find themselves trapped in a grander plot facing grand witches, allying with good witches, and unlocking the mysteries of their past.

Key Plot Elements: Keeping the past hidden in mystery so that the siblings could unravel it themselves at the height of the plot.  A higher sense of duty and a passion to discover what really happened in the past keep the witch hunters on the job - to both eradicate all witches in the land and protect the villages.

Audience: Younger fans to the fantasy genre.

Go see it in 3D: If you like getting shot at by arrows, or getting flayed by wooden shrapnel as powerful machinery or witches tear through trees.

Previews: Jack the Giant Slayer, Star Trek: Into Darkness, G.I. Joe: Retaliation, Oz the Great and Powerful

#8 - The Art of Game Design - Chapters 27,28,29

Chapter 27 - Your Game will Probably have a Client

Much like building any software, your game will have a client whether its you, or someone else.  And a key to the success of building said software or game, is the relationship between you and the client.  For games, it is often the case that designer and client are one and the same.  However when the client is someone else, typically someone with no gaming experience or knowledge, then there may be a few problems.  An outline of how to address and confront such problems is in chapter 27.  Most important is the introduction of Lens #94: Know your client, and understand the words, mind, and heart of the client.  In this way, you can in essence, "merge" with the client and it becomes nearly the case of when you the designer, actually are the client.

Chapter 28 - The Game Designer gives a Pitch

After all, the reasons we enjoy making games may just be for fun, but in the long run, we're all in this to make a little money out of it.  And before you can get paid, you usually need to sell the game to people.  In order to do that, you need to pitch the game idea to people.  Since it won't normally be you that actually sells the game as a vendor, you'll need to talk to someone that can - i.e. publishers.  Pitching the game is the subject of this chapter and Jesse Schell gives 12 tips for delivering that all-important pitch.  Some of the more important tips include being confident, preparation and organization.  This culminates in the Lens #95: Lens of the Pitch.  It is important to know how to pitch your game and show others why the game should sell.

Chapter 29 - The Designer and Client want the Game to Profit

Since the goal of publishing a game is to make profit, we should as game designers, understand the business model to making profit at least in some necessary ways.  Schell outlines that some of the necessary ways are in understanding where money goes when a player buys a game off a retailer's shelves, knowing how many units sold will "break even", and other figures such as cost of marketing and development, and how much money income is expected from the sales.  This chapter puts it all into a useful tip, the Lens #96: The Lens of Profit.  Game design isn't just a hobby, it's a business too.  Perhaps game designers really are a jack of all trades.

#7 - Processing Language

Processing is a very simple scripting language used to develop graphics.  In this post, I'll demonstrate a very simple and cool graphic that I developed in a little under an hour.

To begin, have a visit at http://processing.org/ and download the package for your platform.  Typically you don't need to install it and you can find an executable interface inside, where you can quickly begin your scripting and be on your merry way to graphical goodness.

A few tutorials will show that most programs should have a standard flow.  To begin with, let's setup the setup() function which will handle most needed initialization parameters and create the window for your graphic to be drawn onto.

void setup() {
  size(640, 480);
}

The next step is to setup the draw() function, which will continuously loop while the script is running, up until the window is closed.  Most drawing occurs with the use of primitives such as quadrilaterals or triangles, but there are more complex tools at the disposal of the more advanced Processing programmer.  I stuck with using quads the most, and built a space ship fighter by piecing together a ship hull, two wings, a gun on each wing, a nose cap, a thruster base, and the thruster flames.  (The image for my inspiration is from Star Wars: http://wallpapersus.com/wp-content/uploads/2012/09/Star-Wars-X-Wing-Fighter-Space-Ship.jpg)

Once the ship and its primitives were assigned coordinates, we give the shapes a fill color and an outline (stroke) color.  This is easily done with the stroke() and fill() commands prior to drawing any primitive.  Finally, to show the ship off in all its glory with a little more flair, we rotate the ship as though it were gliding in its hangar as though prancing down an outfitter's runway, using the rotate and translate commands (these are tricky).  But the secret is to translate the origin of the drawing panel to the center of your graphic, do the rotation, then translate the origin back to where it was.  The code all in all is as follows:

float angle;

float jitter;

void setup() {

  size(640, 480);
}
void draw() {
 
  color fire_engine_red = color(206, 32, 41);
  color chrome = color(225, 237, 207);
 
 
  fill(255);
 
  background(51);
  fill(chrome);
  stroke(0);
 
  // Angle for Ship Hangar Rotation
  jitter = 0.02;
  angle = angle + jitter;
 
  // Rotate the Ship in its Hangar
  translate(340,200);
  rotate(angle);
  translate(-340,-200);
  // Ship Hull
  quad(300,300, 380, 300, 345, 110, 335, 110);
 
  // Ship Left Wing
  quad(300,300, 210, 285, 220, 225, 310, 240);
 
  // Ship Right Wing
  quad(380,300, 470, 285, 460, 225, 370, 240);
 
  // Ship Rear Thruster Component
  quad(300,300, 380, 300, 380, 330, 300, 330);
 
  // Ship left Gun
  quad(220, 225, 238, 130, 242, 130, 240, 228);
 
  // Ship Right Gun
  quad(460, 225, 436, 130, 432, 130, 440, 228);
 
  // Ship Nose
  arc(340, 110, 10, 20, PI, TWO_PI);
 
  // Ship Thruster
  fill(fire_engine_red);
  arc(340, 330, 80, 120, 0, PI);
}

#6 - The Last Stand (Film, 2013)

Summary: An escaped fugitive and cartel boss in an elaborate plan to return to Mexico across a constructed bridge and an extremely fast car races south from Las Vegas towards the peaceful town of Sommerton, where the Sheriff (Arnold Schwarzenegger) is prepared to uphold honor over restlessness on his day off to prepare a last stand against overwhelming odds and outmatched arms.

Selling Aspects: Arnold Schwarzenegger, sure to attract fans, is still kicking ass to this day and selling comedy with his age and restlessness.  Action and gun fire, criminal masterminding, fast paced car racing, emotional experiences and light comedy and romance also help sell the movie to fans.

Key Plot Element(s): Jerry, the one deputy, although silly and inexperienced, wants to get out and go where the action is, because Sommerton is peaceful and nothing will ever happen there.  When cased on the murder of a local farmer, he is all too anxious to investigate when he walks into the nest of criminals and undertakes heavy gun fire.  Although ironic that the action would come to him, it was important and necessary that he die so that the other deputies and the Sheriff are fueled with that emotional fire to uphold the last stand and win one for Jerry.

Audience: Those who enjoy action and violence in gun fights and police fights, especially older married couples and younger single guys.

Previews: A Good Day to Die Hard, Now You See Me, Red 2, Bullet To The Head

#5 - Procedural Content Generation

Procedural Content Generation (PCG) is a field of games studies and computer science where methods of automated content generation are studied and researched.  When we talk about PCG, we will need to define the terms very carefully.

Game World: The virtual world comprising of the game environment and all its entities.
The Character Self: The entity that you control inside the game world.
Characters: Entities in the game that you can interact with, via your character self.
Game: The competitive goal of the character self in the game world.
Game Content: Anything that the character self encounters within the game world.
Gameplay: Anything that the character self can do in the game world.

Of game content, which we will typically simplify as simply content, there are two broad categories that we address:

Random Game Content: Content that changes after the character self encounters it.
Static Game Content: Content that never changes.

It's important to note that PCG doesn't always generate random game content, so let's break that down.  In one type, we use PCG to generate content that is random, and in the other manner, we use it as developers and later adjust it in some way or use it as-is to deploy as static content.

Random Procedural Content Generation: Generation of game content that is deployed as random game content.
Static Procedural Content Generation: Generation of game content in an automated and random manner, but is later deployed as static content.

PCG can be further categorized, but the kind that I want to focus on is the automated generation of levels during runtime of the game: Level Generation.  Again this can be static or random, depending on the needs of the designer.  For static level generation, levels are generated automatically via some algorithm, and then the designer takes over and decides whether to adjust it further or to use it as the decided static content for the game.  In random level generation, levels are generated on the fly while the gamer plays.

In the area of random level generation, I've managed to generate random levels using a common algorithm known as the BSP-Tree (Binary Space Partion) algorithm, with some tweaks to make the dungeons seem more realistic - by adding rooms and perturbing the corners to give the dungeon a more "cavey" feel.

PCG is a relatively new field that shows a lot of promise.  Algorithms can be used to aid the game designer and/or to provide longer lasting fun and fresh content.  But anytime we deploy a new technique, we need to ask ourselves if it is really helping, so we need to define what "helping" means with more specificity - and that is currently the problem to address with the field.

#4 - CS493 - Why I would take the Course

CS493 - Week 1 Writing

My name is Joseph Krall, and I'm a Ph.D. student here at the West Virginia University.  I study games for my thesis and study software engineering and computer science for ways to improve upon both the thesis and the game industry.  My thesis is something I'd like to call the "Theory of Fun", which handles an approach on entertainment in which "fun" is the desirable state of mind that we help acclimate players into and keep them there.

My whole life I'd been interested in video games and much of my Ph.D. thesis is based on the study of games.  I thought perhaps I'd get the chance to make some more games through this class and fill in some facets perhaps, of what I have yet to learn in the field.  I see this being one of the more fun classes I'd ever had and as a chance to impress and gain some exposure.

To me, the study of games is a study on psychology of the human desire in terms of what it means for a game to be fun - which is of course, the ultimate goal of any game in providing entertainment, in that it can provide for immersion of the human psyche into the game world - a world where rules are different and often reflective of real world values.  Though most people understand the differences between immersed worlds and the real world, there are those that cannot - particularly the mentally challenged and the young.  This perhaps sheds my view on violence in video games.

# 3: Multiobjective Optimization (MOO)

In search based software engineering (SBSE), we come across the problem of multiobjective optimization (MOO).  This problem can best be explained in terms of math functions.  Given an input vector X = [x1, x2, ..., xi], and a set of objective functions, Y = [f1(X), f2(X), ..., fj(X)], we'd like to know for which X are the Y optimized.

An example is my own dumb "moo problem":
 - We start with three input variables: X  = [x1, x2, x3], each xi bounded between [-2,2]
 - And define two output Y variables as follows:
 - - - f1(X) = -3*x1 + 2*x2
 - -  -f2(X) = 3*x3 + -2*x2

Imagine generating thousands of random sample inputs for the X.  Then evaluate the objective functions f1 and f2.  Create the goal of minimizing f1 and minimizing f2.  For which input vectors X are f1 and f2 the smallest?  In SBSE, the input vector X is a set of "decisions", and the output vector Y is a set of "objectives" that we want to minimize.

The example I used here is a very simple made-up random problem.  In reality there are dozens of such models such as Fonseca, Sriniva, ConstrEx, ZDT1, Golinski, and many more.  Note that some of these are constrained models, and some aren't.  The idea of constraints comes into play about additional bounds to the input X variables.

There are algorithms that can optimize solutions for such problems like this automatically for us, most notably NSGAII and SPEA2.  In my own research, we are experimenting with a newer technology known as RRSL (Rapid Recursive Spectral Learning.)  The use of these algorithms for MOO is often known as MOEA (Multiobjective Evolutionary Algorithm).

In a simpler world, where is only one objective to optimize, we can employ simpler methods such as KEYS or KEYS2.  But more than often, we're interested in more than just a single objective.

#2 - Second Post - My Life as a Game Programmer

I am very passionate about gaming and I find it a wonderful opportunity to provide entertainment to others in the form of creating my own games.  Over the course of my education career, I've developed many games.  I'll try to outline some of them here.  This probably also gives off a good impression about my programming knowledge.

2003 - I worked on and developed a cover of Monopoly that I called Joenopoly.  I renamed all the tiles and created new images for most everything.  It was built in a now, very old version of Visual Basic.  I didn't know much about programming back then, but I knew I had a passion for developing games.  This project served as a senior project at High School for graduation.

2005 - In Ada, a very strict programming language used to learn programming structures in general, I developed a terminal/console based game in which the player moved across a series of rooms, some of which hosted monsters that you had to fight.  This was a well controlled RPG of sorts, but it was also a very small game.  I'd always preferred RPG games when playing them on my own, and so I'd always tried to make one of my own as well.  But they are not very easy to make - enemies with stats such as HP, MP, strength, defense, and more all contribute to a very challenging task of balance with the "hero's" stats of the same kind.

2006 - Have learned Java and put some collective studies on AI to the task in a simple turn based RPG game in which a player combats enemies by walking into them.  This one was called "Avalonn" - artificial valley of neural nets.  The enemies chose what to do for themselves, based on conditions around them.

2006 - "Rocelia" - another Visual Basic project which featured an incomplete but vast world in which you encounter random enemies in a pop-up battle display of sorts.  Had a small story and a sliding overworld as you walk across it.

2007 - "Bingo Quest" - Yet another Visual Basic project in which the objective was to play Bingo and win games to fuel your rocket and play some more Bingo on other planets

2008 - Introduction to OpenGL in c++.  Built a game called "Blokuest" in which you were a block in a puzzle world with switches, crystals and targets to reach.  Rendered in full 3D with a number of OpenGL techniques.

2009 - More OpenGL: built a game called "Getris", which stands for Graphical Tetris.  This was standard Tetris version fully rendered in 3D, in which the blocks had surfaces that could be adjusted to give the impression of reflective surfaces, shiny surfaces, rough or cloth surfaces, and could cast shadows beneath them.

2010 - Another OpenGL Project: "Dimensia", my attempt at splitting "Fun" into four dimensions.  This game played pretty much exactly like Zelda, except you could use a sword, a side swiping axe, a bow or a magic staff.

2011 - "AiMazed2D" - Lua Version.  This game featured randomly generated dungeon/mazes in which there was a hidden key and exit for the player to locate before the computer did so in its own randomly generated dungeon.

2011 - More Lua Projects: Built "Attack of the Robots", "Evolution Simulation" and "Grand Theft Wumpus" - three very simple projects outlined in a book designed to teach LISP.

2012 - "Qubey's Deep Dungeon".  Based on AiMazed2D, with random dungeon generation and exploration as the core.  I got in touch with some people from the west coast who are interested in  perhaps putting together a mobile games development start-up.  In my eyes, I hope Qubey can be the premier launching project, and there are some really good hopes here.  We have future projects we'd like to develop as well.

#1 - First Post - Summary of Ph.D. Life

My name is Joseph Krall and I am a Ph.D. student at the West Virginia University.  I'm studying Computer Science with a research interest in gaming, psychology of entertainment, software engineering, data mining, and search based software engineering.  I am developing and expanding upon a thesis that I call "The Theory of Fun", in which I outline key components to fun and address problems of creating fun video games, and provide ways to mitigate risk involved in development.

I began my Ph.D. studies in Fall 2010.  My earliest research project was an attempt to break "Fun" into four dimensions - Story, Originality, Gameplay, and Replayability.  Since then, I have expanded on what it means for a person to have "Fun" by studying cognitive psychology and have outlined the core of my thesis: "Fun" is a desirable state of mind and entertainment is the medium which helps a player reach "fun".  When a person is in this desirable state of mind, they are immersed into a different world in which the rules of nature and believability are different.  So we can newly address the problem of providing fun as two things: 1) Playability - helping a player reach the fun state of mind, and 2) Replayability - keeping a player at the fun state of mind.

To study games however, it is difficult to collect data.  We turn to Search Based Software Engineering to aid with this problem.  I was pointed to an existing project known as POM - which is a software project emulator.  The goal was that POM could be used to simulate a real world software project in mere seconds instead of months and years.  Such a simulation could be used to study the effects of real world parameters such as culture (how much a project changes), team sizes and more.  But as simulations go, we'd like to prove any claims in the real world as well.  Although we learn using POM, it requires thousands of simulations to find optimal solutions.  Our latest research focuses on vastly reducing the number of simulations needed, from thousands to hundreds.  This in effect helps our study on games in the same way.

Quick "About me" resume of sorts: http://ai-at-wvu.blogspot.com/2012/10/who-is-joe.html