This week I'm trying to look at three categories different from the 'entertainment games'; ARGs, Art Games and Serious Games.
First up are ARGs:
Why you should care about ARGS
-by Margaret Robertson
"Why you should care about ARGs was a talk Margaret Robertson did at the Develop Brighton Conference in 2008. Is this talk she pointed out that there are three major problems with ARGs. For one, nobody knows what they are, they're not all that great and last of all, they're dead.
Robertson then continues to adress these problems, starting with defining ARGs, and arguing that Halo is in fact an ARG. Alternative Reality Game, where an alternative, fictional reality becomes your own, and you no longer have to obey by the laws of the 'real' reality.
As Margaret Robertson delicately puts it: "I think ARGs are a bit shit", and she makes a pretty convincing point as to why that would be: They have no proper beginning, middle or end. ARGs tend to flourish in the early to middle stages when the entire game blows up and goes into full swing. Then people start losing track of it, get bored with it or lose interest. And when the game nears the end it quickly fades away.
Then there's the problem of attracting players. Most ARGs use the 'rabbit hole' approach, trying to lure the player into the game by using a trail of clues. Problems arise when players start missing clues, can't be bothered to solve the riddles and puzzles, or just can't be arsed to jump through hoops just to be sucked into a game.
So how are ARGs dead? Well, according to Robertsen it's because of the two problems mentioned earlier that 'traditional' ARGs are starting to die out, and the designers have moved on to nuARGs, which try to move away from all the old conventions of narrative, puzzles and mysteries, instead often functioning without any of those.
Then, if ARGs are dead, why should we care? Well, we can learn certain things from them. We can learn to link our games to the reality of our players, crossing mixing the real world with the fictional world we create, or going cross-medium. We can learn to respect that players have a life outside playing our videogames, and we can use that against them to try and lure them back into the game. We can learn from ARGs that unsolvable challenges and puzzles in games aren't neccessarly bad, as long as they don't break the progression of the game. A challenge that seems impossible can create a whole new buzz between players trying to work together to overcome and obstacle the designer hasn't even figured out himself.
All in all, there's a lot we can learn from ARGs, but from their weak and their strong points. In my opinion, we're seeing a gradual shift towards more social gaming, where people are moving away from their computer screens and gather to play video-games, primarily because of the rise of consoles, but also because of the evolution of different platforms, such as the iPhone and online applications such as FaceBook and Twitter. Using principles from ARGs, by looking further than just the game we're offering on the platfrom we're developing for, we can create a broader spectrum of challenges and get people engaged in on different levels without forcing them to participate.
The Path For Art Games
-By Leigh Alexander
In this article Alexander discusses why players seem to demand 'more' from games, but when such games are created, they never seem to be a commercial success. He looks at several different games and attempts to analyze why they aren't as popular as some people would expect.
The first point Alexander makes is that while players might demand certain things, that isn't always what they want. Case in point; Mad World and GTA: Chinatown Wars, on the Wii and DS respectively. Both platforms have had long time demands for more mature games, but when they came out, especially Mad World didn't do particularly well, leading to the suspicion that gamers might not always be completely in touch with what they want, or maybe they demand things for platforms they don't even own.
He then moves to investigate The Path, trying to look into how and why this game isn't a commercial success. One of the arguments Alexander brings forward is that gamers are alienated by the design of The Path, finding it hard to cope with a game that falls outside the traditional views people have on video games. But he also shows through an interview with the Path's creators that they themselves hardly have any idea who they're making their game for, or even worse, they're making a game for people who don't like games.
And this is what seems to be the crux of the problem. The 'art game makers' tend to focus outside of the gamers market, which is usually oblivious to the very existence of these games, or is under the assumption that they don't like games at all. The gamers themselves (rightfully) feel that they're not targetted by the games' creators.
I found the article an enjoyable read, as it was quite objective and just showed the different opinions on art games. The most interesting to read were those of the Tale of Tales game designers, which I really had issues with. They admitted to be creating a game for people didn't like games, and agreed that perhaps the Path wasn't a game at all, leading me to believe that they are pretty clueless as to what they were doing when they built the game, relying solemnly on the novelty of the concept to get publicity. What bothers me the most is that 'art games' are often gimmicky, or exceptionally narrative in nature, with all the problems that these games already tend to have. Their gimicky nature makes them short, and often easy to figure out and then beat. The narrative issues I have discussed in earlier reports. But in the end, I guess all Art games fall victim to the same problems Narrative Games have. When we use a game as a creative expression, when we use it to make 'art', we do the same as when we try to tell a story through a game. An artist who paints a picture is the storyteller, the onlooker the person listening to the story, and as such passive. When we create an 'art game' we start telling a story, leaving the player a passive onlooker with stints of interaction.
zaterdag 31 oktober 2009
zaterdag 24 oktober 2009
Rules to Play by: The Google Method
So after trying several different books and becoming incredibly bored with them for speaking is such general terms that I could find nothing worth writing about (in a positive or negative fashion) I figured I'd turn to the tool of my generation: Google. It's good to see how many interesting hits you can get from Google by searching for 'How to make a fun game' or 'How to design a video game'. Some of the articles were actually quite interesting, made me smile or got me genuinely annoyed. Here's a small selection.
How to make a game fun and interesting
-GDC 2009 Intentionality and fault tolerance, Clint Hocking
This article, written by Charlie Demerjian for the Enquirer, Clint Hocking describes how Far Cry 2 attemtped to tackle the difficulty of designing Intentionality in a game. Intentionality, as Demerjian explains, "is best summed up as allowing the player to figure out the goals and how to accomplish them given a few tools and implicit rules." Intentionality can become problematic when a player has too much room for improvisation and can very well go beyond the boundaries set by the game designer. This is illustrated by the example of Splinter Cell, where a player used a bunch of cameras to guide an NPC into doing something unforseen by the Game Designers. This becomes especially problematic when the player can eventually break the game (The Elder Scrolls: Morrowind was notorious for a design mistake which allowed the player to break the game in under 30 minutes)
Intentionality as such becomes the ability for a player to improvise within the boundaries set by the designer, without the ability to break the game. When Ubisoft first began development on Far Cry 2, they planned heavily on using Intentionality. Designing for Intentionality requires a different approach from 'linear' game design, as it should allow the player to have more freedom than usual. Because of this, Ubisoft used several 'Design Pillars'. Important aspects of the game that would work together to create intentionality. They divided the game into four different archetypical elements; Structural, Environments, AI Systems and Objects. These aspects were then further divided in different elements that together formed a system where every element influenced the other.
During development however, a lot of these pillars were cut out of the game, mostly because they were too difficult to implement implicitly. In the end, four pillars remained. This is where the entire game went down a different path, turning from a game where a player could plan strategic situations and handle challenges the way he wanted to, to a run of the mill FPS that still had mechanics based on the earlier 9 pillars. This in turn created a game that felt unbalanced, where the player's actions had certain consequences implied, but were never felt by the player. The problem was two-fold. On one hand, Far Cry 2 had become a regular FPS, which isn't necessarily a bad thing. On the other hand, the level-design was still based on the old system, but the gameplay no longer supported that design.
The second half of Clint Hocking's talk was on Fault Tolerance. Fault Tolerance is about games being supportive to a player who makes mistakes. It relies on two concepts: Composition and Execution. Composition is the planning fase, where the player sets out his strategy to overcome a certain challenge. Execution is the actual execution of a plan, or the lack thereof. Thief was a Composition heavy game, Wolfenstein 3D an execution heavy game. Most games apply both concepts, but tend to lean to one or the other side of the spectrum. The problem with Composition heavy games is that players tend to be penalized heavily when their plans fail. The Fault Tolerance is virtually non-existant. Execution heavy games deal less with this problem, as composition is less of a factor there. But still, when a player makes a mistake in an Execution heavy game, he can feel frustrated because he might feel powerless. The game 'took him by surprise' and there was no way of anticipating what he should have done. A Fault Intolerant game can quickly become frustrating when a player needs to replay entire segments of the game over and over again just because he made a little mistake. Hocking made a point of Far Cry 2's death system during missions, where a NPC ally would swoop in to save your ass, as long as you kept the NPC safe. Even if you got killed, your ally would drag you away from the firefight and revive you, and you'd be good to go as long as you made sure the NPC didn't die later on.
Hocking's talk makes some very interesting points, eventhough Demerjian never seems to get them, or bother to highlight them.
The idea of using Pillars to design systems that influence eachother is a very interesting approach, as it allows the designer to constantly maintain a clear focus on what is important to the system, and what isn´t. The Fault Tolerance aspect of games might be a very interesting topic of discussion. We all remember games like Contra, which were punishing in their difficulty, but memorable because of it. Making a game too tolerant to a player´s mistakes would make it boring, taking away the player´s sense of accomplishment whenever he defeats a challange. (Think of Prince of Persia, Sands of Time. Rewinding the game everytime you died certainly made the player reckless, or less appreciative of the game's challenges).
How Game Mechanics Can Make Your App More Fun
-ETech lecture, Amy Jo Kim
Another lecture report, this one written by Bruce Stewart for ETech, on Amy Jo Kim's lecture about how Game Mechanics can make Apps more fun. Kim's lecture mentions five key game mechanics that can be applied outside game design to make applications more interesting.
Kim named five key elements:
-collecting things
-earning points
-providing feedback
-exchanges
-cusomization
These five elements are all traits that come from game design, but can be applied to a variety of non-entertainment applications, primarily in a social setting such as MySpace, which Kim uses as an example.
On MySpace a user collects 'friends', similar to how a player can collect items within a Game. Earning points is done by other users giving the main user ratings, or feedback to what they're doing.
Feedback is given by the application itself, showing the user how many friends he or she has, or how many pictures/movies/music he or she has uploaded.
Exchanges are much like collecting, but one-sided. Where an invitation to become another user's friend requires the other user's consent or feedback, an Exchange can be seen as leaving a comment on another user's page.
Customization is one of the things MySpace is known (and most dreaded) for. Every user has his own page which he or she can customize the way he or she sees fit, much like how players can modify and customize their characters in popular videogames.
By looking at these elements we can draw a line towards more social experiences in gaming. The past few years we see a trend where games become more and more of a social event, drawing players away from behind their computer screen and getting them to interact with eachother as integral part of the game itself. This article is interesting because we can try to turn it around, looking at ways social interaction, or characteristics of social interaction, can be applied to gaming in general.
How to make a game fun and interesting
-GDC 2009 Intentionality and fault tolerance, Clint Hocking
This article, written by Charlie Demerjian for the Enquirer, Clint Hocking describes how Far Cry 2 attemtped to tackle the difficulty of designing Intentionality in a game. Intentionality, as Demerjian explains, "is best summed up as allowing the player to figure out the goals and how to accomplish them given a few tools and implicit rules." Intentionality can become problematic when a player has too much room for improvisation and can very well go beyond the boundaries set by the game designer. This is illustrated by the example of Splinter Cell, where a player used a bunch of cameras to guide an NPC into doing something unforseen by the Game Designers. This becomes especially problematic when the player can eventually break the game (The Elder Scrolls: Morrowind was notorious for a design mistake which allowed the player to break the game in under 30 minutes)
Intentionality as such becomes the ability for a player to improvise within the boundaries set by the designer, without the ability to break the game. When Ubisoft first began development on Far Cry 2, they planned heavily on using Intentionality. Designing for Intentionality requires a different approach from 'linear' game design, as it should allow the player to have more freedom than usual. Because of this, Ubisoft used several 'Design Pillars'. Important aspects of the game that would work together to create intentionality. They divided the game into four different archetypical elements; Structural, Environments, AI Systems and Objects. These aspects were then further divided in different elements that together formed a system where every element influenced the other.
During development however, a lot of these pillars were cut out of the game, mostly because they were too difficult to implement implicitly. In the end, four pillars remained. This is where the entire game went down a different path, turning from a game where a player could plan strategic situations and handle challenges the way he wanted to, to a run of the mill FPS that still had mechanics based on the earlier 9 pillars. This in turn created a game that felt unbalanced, where the player's actions had certain consequences implied, but were never felt by the player. The problem was two-fold. On one hand, Far Cry 2 had become a regular FPS, which isn't necessarily a bad thing. On the other hand, the level-design was still based on the old system, but the gameplay no longer supported that design.
The second half of Clint Hocking's talk was on Fault Tolerance. Fault Tolerance is about games being supportive to a player who makes mistakes. It relies on two concepts: Composition and Execution. Composition is the planning fase, where the player sets out his strategy to overcome a certain challenge. Execution is the actual execution of a plan, or the lack thereof. Thief was a Composition heavy game, Wolfenstein 3D an execution heavy game. Most games apply both concepts, but tend to lean to one or the other side of the spectrum. The problem with Composition heavy games is that players tend to be penalized heavily when their plans fail. The Fault Tolerance is virtually non-existant. Execution heavy games deal less with this problem, as composition is less of a factor there. But still, when a player makes a mistake in an Execution heavy game, he can feel frustrated because he might feel powerless. The game 'took him by surprise' and there was no way of anticipating what he should have done. A Fault Intolerant game can quickly become frustrating when a player needs to replay entire segments of the game over and over again just because he made a little mistake. Hocking made a point of Far Cry 2's death system during missions, where a NPC ally would swoop in to save your ass, as long as you kept the NPC safe. Even if you got killed, your ally would drag you away from the firefight and revive you, and you'd be good to go as long as you made sure the NPC didn't die later on.
Hocking's talk makes some very interesting points, eventhough Demerjian never seems to get them, or bother to highlight them.
The idea of using Pillars to design systems that influence eachother is a very interesting approach, as it allows the designer to constantly maintain a clear focus on what is important to the system, and what isn´t. The Fault Tolerance aspect of games might be a very interesting topic of discussion. We all remember games like Contra, which were punishing in their difficulty, but memorable because of it. Making a game too tolerant to a player´s mistakes would make it boring, taking away the player´s sense of accomplishment whenever he defeats a challange. (Think of Prince of Persia, Sands of Time. Rewinding the game everytime you died certainly made the player reckless, or less appreciative of the game's challenges).
How Game Mechanics Can Make Your App More Fun
-ETech lecture, Amy Jo Kim
Another lecture report, this one written by Bruce Stewart for ETech, on Amy Jo Kim's lecture about how Game Mechanics can make Apps more fun. Kim's lecture mentions five key game mechanics that can be applied outside game design to make applications more interesting.
Kim named five key elements:
-collecting things
-earning points
-providing feedback
-exchanges
-cusomization
These five elements are all traits that come from game design, but can be applied to a variety of non-entertainment applications, primarily in a social setting such as MySpace, which Kim uses as an example.
On MySpace a user collects 'friends', similar to how a player can collect items within a Game. Earning points is done by other users giving the main user ratings, or feedback to what they're doing.
Feedback is given by the application itself, showing the user how many friends he or she has, or how many pictures/movies/music he or she has uploaded.
Exchanges are much like collecting, but one-sided. Where an invitation to become another user's friend requires the other user's consent or feedback, an Exchange can be seen as leaving a comment on another user's page.
Customization is one of the things MySpace is known (and most dreaded) for. Every user has his own page which he or she can customize the way he or she sees fit, much like how players can modify and customize their characters in popular videogames.
By looking at these elements we can draw a line towards more social experiences in gaming. The past few years we see a trend where games become more and more of a social event, drawing players away from behind their computer screen and getting them to interact with eachother as integral part of the game itself. This article is interesting because we can try to turn it around, looking at ways social interaction, or characteristics of social interaction, can be applied to gaming in general.
zaterdag 17 oktober 2009
Rules to Play by: An odd perspective
Having talked about story last week, this week I'll try to look at odd, fun and downright strange ways people view Game Design, the Game Designer him/herself or a specific aspect of Design. Taking extreme, odd or bizarre views on Game Design could prove very useful, as extreme statements often invoke extreme reactions, which is exactly what I want.
What Can the Socratic Method Tell Us About Gameplay?
-by Taekwan Kim
In this article Taekwam Kim attempts to show how the Socratic Method can be applied to Gameplay, focussing primarily on player investment.
Kim first explain the Socratic Method, explaining that there are four basic rules the participants must adhere to:
-At least two voices must be heard
-The voices must be intimately connected to the positions they take
-A participant must say what he really thinks
-Participants must sincerely defend their positions
Kim reasons that the Socratic method can be linked to gameplay in the follow fashion:
-No progress is made unilaterally (No progress is made if only one party is involved)
-No cheating by taking a dishonest position (both the game and the player must abide by their roles, never trespassing into eachother's sphere of influence)
-No simply giving in to the other side for the sake of progression
He tries to make this argument stick by giving the example of two players playing a game of Streetfighter, one being a veteran, the other being new to the game. Kim explains that the new player would feel insulted if the veteran player lost on purpose. (The veteran player would have broken one of the rules of the Socratic Method; He did not sincerely defend his position)
Kim then moves to argue that gameplay equals investment, since a player cannot take on an identity completely at odds with his own behaviour. Kim reasons that there would be no meaning in losing, or winning, as the player has no real investment in the game and it effectively becomes a simulation. Kim attempts to prove this by giving the example of playing chess against yourself, and trying to win with both sides. Since the player will always win, and as such, always lose as well, there's no real investment.
The next paragraph deal with Procedural Narrative, and Kim states that we still experience dialogue scenes in videogames as being gameplay because they aren't one-sided events. The reason for this, according to Kim, is that dialogue in games aren't simulations, where the Author tells the story to the player. Instead, they are honest exchanges between clearly defined and established identities (i.e. NPC vs Player), where the player is invested in his own identity and makes choices accordingly.
Following up on this, Kim claims we shouldn't focus on non-linearity per se, but on honest responses to players. In Knights of the Old Republic, we have to engage in petty acts of crime to become a villainous Sith Lord. To Kim, this isn't an honest response to the player's identity, and as such, will leave the player disgruntled.
In a closing statement, Kim attempts to define the word 'game'. He first explains how Carl Jung observed that test-subjects always attempt to 'game' a test, believing that the test is a direct, intellectual challenge and that there is an expected outcome. They create an identity for themselves and attempt to answer the test so that the outcome reflects the identity they try to convey. To Kim, this is the essence of a game; Sculpting your own identity, and having a world that responds to your identity in an honest manner.
I found Kim's article quite interesting to read, although there are several things I can't agree on, or feel that he misses a few crucial points.
In the first section, where Kim explains how the Socratic Method can be applied to game design, he gives the Streetfighter example, later on he tries to show how investment works by using Chess as an example. These are both multiplayer games, and ofcourse they tend to fail when one of the Socratic Method's rules isn't being followed. This however, is due to the fact that the Socratic Method relies on two participants who both abide by the rules. If one participant falls short (as detailed in the Streetfighter example) or is absent (as detailed in the chess example) Kim's argument is solid. However, when we look at singleplayer games, the second participant isn't a flesh and blood player, but a system, designed and built by other people. While I'm sure that the Socratic Method can be applied to such systems as well, I was a little disappointed that Kim didn't elaborate on his theory enough to talk venture into single player games.
What I found interesting was what Kim wrote about investment. When I read it first, my instinct was to disagree with him. Where Kim reasons that a player can't take a role that's contrary to his own behaviour, I reasoned that players played games exactly because they could act contrary to their own behaviour. No sane person would run over people while shooting from a car, then jump out and fire a rocketlauncher at a police helicopter. But then I realised that perhaps Kim wasn't talking so much about 'in-game' behaviour, but about gameplay behaviour. No player will want to play a game that he can't win, or where he can't score, because that is our behaviour as players. Certain goals have to be met, and we have a clear expectation of what these goals are. We won't take any 'identity' in game that moves directly against these goals.
What I really couldn't agree with however, was Kim's definition of a game, as there are plenty of games that do not allow for 'identity sculpting', primarily singleplayer games such as Tetris. (Yes, Pong does allow for identity sculpting, as multiplayer games (and therefore social interaction) always rely on identity) As such, I don't feel Identity Sculpting can be used as a definition for Games in general.
Now, the biggest issue is: How does this actually help me? While Kim makes some nice observations, he makes very few points about how the Socratic Method can be of actual use when designing a game. Still, there is one thing I'd like to take from this article:
Always keep in mind your player's motive (or identity) and treat him honestly in regard to that identity. Look carefully at who your player is. If he is supposed to be an epic villain, don't bother him with mundane stuff.
Gearbox's Pitchford: Magic, Video Games Have A Lot In Common
-Part of a Gamasutra Interview
In this article, Gamasutra interviews Gearbox co-founder Randy Pitchford. During this interview Pitchford speaks about his past profession as a magician, and how this relates to Game Design. Apperantly Gamasutra thought this bit was so special, they actually dedicated a short feature to it.
In the interview, Pitchford explains how Game Design and Magic aren't as different as one would think at first glance. They're in the same business; entertainment. It's all about crafting illusions, about immersing your crowd in something they want to believe in. It's about misdirection, attracting someone's attention and then surprising them.
Pitchford illustrates his statement by using an example from Call of Duty. Whenever the player stays in the same place for too long during a firefight, he'll suddenly get a grenade thrown at him. No actual enmey threw the grenade at the player; the game just spawns it near to the player to get him to move from his position and participate in the firefight. Once a player understands this, he'll complain. He'll state he hates the spawning grenades. And eventhough the designer knows that the player doesn't hate it (afterall, if the grenades didn't spawn there the player would be able to stay in relative safety at all times and therefore never experience danger, making for a bland experience), he will have to change the trick.
In the end it's much like a card trick. As long as you don't understand how it works, it's special. Once you figure it out, the trick becomes much less spectacular. It's not that the trick lost it's value, but the magician will need to come up with a new one to keep your attention.
I found this article pretty interesting, but not because I love magic that much. In the end I think it's about understanding what your user wants. It's about being cocky enough to tell the player 'You don't hate the fact that I spawn grenades at your feet, you hate the fact that you figured it out.' It's about understanding that as a Designer, you should be aware of how you manipulate your player, and if they complain about something, it might not always be in your best interest to immediately change your game on their behalf, but to look at why the player is complaining. If it's just because he figured out your trick, think of a new one rather than giving the player exactly what he wants. In the end, I guess a designer has to be cocky enough to say: "You want to play this, trust me."
What Can the Socratic Method Tell Us About Gameplay?
-by Taekwan Kim
In this article Taekwam Kim attempts to show how the Socratic Method can be applied to Gameplay, focussing primarily on player investment.
Kim first explain the Socratic Method, explaining that there are four basic rules the participants must adhere to:
-At least two voices must be heard
-The voices must be intimately connected to the positions they take
-A participant must say what he really thinks
-Participants must sincerely defend their positions
Kim reasons that the Socratic method can be linked to gameplay in the follow fashion:
-No progress is made unilaterally (No progress is made if only one party is involved)
-No cheating by taking a dishonest position (both the game and the player must abide by their roles, never trespassing into eachother's sphere of influence)
-No simply giving in to the other side for the sake of progression
He tries to make this argument stick by giving the example of two players playing a game of Streetfighter, one being a veteran, the other being new to the game. Kim explains that the new player would feel insulted if the veteran player lost on purpose. (The veteran player would have broken one of the rules of the Socratic Method; He did not sincerely defend his position)
Kim then moves to argue that gameplay equals investment, since a player cannot take on an identity completely at odds with his own behaviour. Kim reasons that there would be no meaning in losing, or winning, as the player has no real investment in the game and it effectively becomes a simulation. Kim attempts to prove this by giving the example of playing chess against yourself, and trying to win with both sides. Since the player will always win, and as such, always lose as well, there's no real investment.
The next paragraph deal with Procedural Narrative, and Kim states that we still experience dialogue scenes in videogames as being gameplay because they aren't one-sided events. The reason for this, according to Kim, is that dialogue in games aren't simulations, where the Author tells the story to the player. Instead, they are honest exchanges between clearly defined and established identities (i.e. NPC vs Player), where the player is invested in his own identity and makes choices accordingly.
Following up on this, Kim claims we shouldn't focus on non-linearity per se, but on honest responses to players. In Knights of the Old Republic, we have to engage in petty acts of crime to become a villainous Sith Lord. To Kim, this isn't an honest response to the player's identity, and as such, will leave the player disgruntled.
In a closing statement, Kim attempts to define the word 'game'. He first explains how Carl Jung observed that test-subjects always attempt to 'game' a test, believing that the test is a direct, intellectual challenge and that there is an expected outcome. They create an identity for themselves and attempt to answer the test so that the outcome reflects the identity they try to convey. To Kim, this is the essence of a game; Sculpting your own identity, and having a world that responds to your identity in an honest manner.
I found Kim's article quite interesting to read, although there are several things I can't agree on, or feel that he misses a few crucial points.
In the first section, where Kim explains how the Socratic Method can be applied to game design, he gives the Streetfighter example, later on he tries to show how investment works by using Chess as an example. These are both multiplayer games, and ofcourse they tend to fail when one of the Socratic Method's rules isn't being followed. This however, is due to the fact that the Socratic Method relies on two participants who both abide by the rules. If one participant falls short (as detailed in the Streetfighter example) or is absent (as detailed in the chess example) Kim's argument is solid. However, when we look at singleplayer games, the second participant isn't a flesh and blood player, but a system, designed and built by other people. While I'm sure that the Socratic Method can be applied to such systems as well, I was a little disappointed that Kim didn't elaborate on his theory enough to talk venture into single player games.
What I found interesting was what Kim wrote about investment. When I read it first, my instinct was to disagree with him. Where Kim reasons that a player can't take a role that's contrary to his own behaviour, I reasoned that players played games exactly because they could act contrary to their own behaviour. No sane person would run over people while shooting from a car, then jump out and fire a rocketlauncher at a police helicopter. But then I realised that perhaps Kim wasn't talking so much about 'in-game' behaviour, but about gameplay behaviour. No player will want to play a game that he can't win, or where he can't score, because that is our behaviour as players. Certain goals have to be met, and we have a clear expectation of what these goals are. We won't take any 'identity' in game that moves directly against these goals.
What I really couldn't agree with however, was Kim's definition of a game, as there are plenty of games that do not allow for 'identity sculpting', primarily singleplayer games such as Tetris. (Yes, Pong does allow for identity sculpting, as multiplayer games (and therefore social interaction) always rely on identity) As such, I don't feel Identity Sculpting can be used as a definition for Games in general.
Now, the biggest issue is: How does this actually help me? While Kim makes some nice observations, he makes very few points about how the Socratic Method can be of actual use when designing a game. Still, there is one thing I'd like to take from this article:
Always keep in mind your player's motive (or identity) and treat him honestly in regard to that identity. Look carefully at who your player is. If he is supposed to be an epic villain, don't bother him with mundane stuff.
Gearbox's Pitchford: Magic, Video Games Have A Lot In Common
-Part of a Gamasutra Interview
In this article, Gamasutra interviews Gearbox co-founder Randy Pitchford. During this interview Pitchford speaks about his past profession as a magician, and how this relates to Game Design. Apperantly Gamasutra thought this bit was so special, they actually dedicated a short feature to it.
In the interview, Pitchford explains how Game Design and Magic aren't as different as one would think at first glance. They're in the same business; entertainment. It's all about crafting illusions, about immersing your crowd in something they want to believe in. It's about misdirection, attracting someone's attention and then surprising them.
Pitchford illustrates his statement by using an example from Call of Duty. Whenever the player stays in the same place for too long during a firefight, he'll suddenly get a grenade thrown at him. No actual enmey threw the grenade at the player; the game just spawns it near to the player to get him to move from his position and participate in the firefight. Once a player understands this, he'll complain. He'll state he hates the spawning grenades. And eventhough the designer knows that the player doesn't hate it (afterall, if the grenades didn't spawn there the player would be able to stay in relative safety at all times and therefore never experience danger, making for a bland experience), he will have to change the trick.
In the end it's much like a card trick. As long as you don't understand how it works, it's special. Once you figure it out, the trick becomes much less spectacular. It's not that the trick lost it's value, but the magician will need to come up with a new one to keep your attention.
I found this article pretty interesting, but not because I love magic that much. In the end I think it's about understanding what your user wants. It's about being cocky enough to tell the player 'You don't hate the fact that I spawn grenades at your feet, you hate the fact that you figured it out.' It's about understanding that as a Designer, you should be aware of how you manipulate your player, and if they complain about something, it might not always be in your best interest to immediately change your game on their behalf, but to look at why the player is complaining. If it's just because he figured out your trick, think of a new one rather than giving the player exactly what he wants. In the end, I guess a designer has to be cocky enough to say: "You want to play this, trust me."
zaterdag 10 oktober 2009
Rules to Play by: Discussing the nature of games and Design with Marc
Marc:
Ik lees theory of fun
dus ik ben nu van mening dat alles een spelletje is
aangezien we er gewoon van leren
en het een andere manier iis van patroonherkenning
Bram:
Dat is wel een hele brede definitie van een spel
Marc:
hij geeft niet echt een definitie van game in die eerste hoofdstukken omdat dat er in feite niet toe doet, wat voor 1 iemand een game is, is voor iemand anders keiharde werkelijkheid
en daarnaast is hij van mening dat de games misschien wel dichter bij de werkelijkheid staan dan hoe wij de werkelijkeid waarnemen
omdat ons hoofd zoveel samenvoegt in patronen etc
vind ik wel mooi om te lezen
Bram:
Mja, maar is een game niet altijd fictie?
Marc:
nee niet dus
Bram:
Of in ieder geval een fictieve representatie van de werkelijkheid?
Marc:
omdat het ene kwestie is van patronen uit de werkelijkheid
ja maar gast
wij nemen de werkelijkheid niet eens waar zoals hij is, dus hoe kanje dan in den beginne al spreken van een nonfictieve representatie van de werkelijheid
die is er niet
wij nemen de werkelijkheid ook niet waar zoals hij is, dus zou je kunnen stellen dat onze werkelijkheid ook maar een spelletje is
Bram:
Mja, misschien. Maar een spel is iets waar je vrijwillig aan deelneemt
De werkelijkheid helaas niet
(Ja, tenzij je zelfmood meerekent)
Marc:
maar dat je er vrijwillig aan deelneemt wil nog niet zeggen dat het fictief is...
Bram:
Een spel heeft een kop en een staart.
Marc:
de werkelijkheid ook
Bram:
True, maar niet vrijwillig
Ik kan een spel beginnen wanneer ik wil
En eindigen wanneer ik wil
Het leven kan ik eindigen wanneer ik dat wil
Maar niet beginnen
En ik doe niet vrijwillig mee, maar omdat ik buiten zelfmoord geen keuze heb.
Marc:
nee hoor, je doet vaak genoeg mee aan het spel van iemand anders zonder dat je daarvoor gekozen hebt. Dan neem je het alleen waar als de werkeljkeid
Bram:
Voorbeeld?
Marc:
maar die persoon kan ghoed met iets bezig zijn wat voor hem een spelletje is en voo rjou bittere ernst
voorbeeld: hoe sommige mensen met elkaar omgaan. Ik weet dat ik als kind dingen wel eens zag als een spelletjes (hoe ik dan met mijn peers omging) maar omdat mijn omgeving dat niet wist is het vervolgens voo rhen de werkelijkheid
terwijl het nog steeds een spelletje is
maar als we hier te lang op doorghaan wordt het meer filosofische kwestie
Bram:
Hahaha, ja
Marc:
en ik moet nog een hoofdstukje lezen
Bram:
Kunst is het concreet houden
Anders slacht Karel je af
Marc:
ja idd
Bram:
Want nog even 1 punt
Hoewel jij dat spel speelde, koos je er zelf voor het te beginnen, en te eindigen. Zo gauw je 'medespeler' door heeft dat jij een spel speelt, kan hij de keuze maken mee te spelen of het te beïndigen.
Bram:
Hahaha
Filosofie staat alleen altijd in de weg van een concreet debat.
Marc:
nee is niet waar, ja trouwens misschien juist wel
Bram:
Het is denk ik ook maar net hoe je Game Design ziet
Marc:
ja zeker waar
Bram:
Ik zelf zie het als een ambacht. Iets concreets.
Anderen mensen, misschien jij ook, zien het filosofischer.
Marc:
en ik geloof niet dat welke vorm van design/kunst een ambacht is. Op het moment datje vormen van kunst als ambacht gaat zien, wordt het lopende band werk (niet letterlijk natuurlijk maar ik kon geen betere term verzinnen zo snel). Maar daarnaast ben ik wel weer van mening dat je kunst als iets concreets kunt zien, iets waar je formele regels aan kunt vasthangen. maar dan moet je die regels ook wel
weer kunnen doorbreken
maja, ik ga ff verder lezen en samenvatten
Bram:
Is goed man
Marc:
misschien moeten we dit msngesprek gewoon op de blog zetten
Bram:
Maar een ambacht zie ik meer als wat jij beschrijft
Juist -geen- lopende band werk.
Maar een werkvorm waarin creativiteit en formaliteit elkaar kruisen.
Marc:
nee, lopende band werk ws ook de evrkeerde term
Bram:
Maatwerk!
Marc:
jaaaa
das wel een goeie
Bram:
Bepaalde principes zijn overdraagbaar
Maar per 'klant' moet je creatief zijn.
Marc:
maar dan wel zo dat de creativiteit ondergeschikt is aan de formaliteit
Bram:
Juist.
Een hoefsmid maakt een hoefijzer. Altijd dezelfde vorm, hetzelfde principe, maar aangepast per paard.
Marc:
idd
maar dat wil ik dus niet met games
dat is voor mij een kunstvorm
Bram:
Ik dus wel
Marc:
een manier om me te uiten
ik ben me heel erg bewust van die formalitiet en ben heel erg bereid om me daar in te schikken olang ik hier op school zit
Bram:
Verschil in redenatie tussen creatie vanuit jezelf, en creatie voor een ander.
Marc:
ja zeker waar
Bram:
Ik rederneer vanuit het laatste. Ik heb geen boodschap
En ik wil de wereld niet verbeteren
Marc:
ikke wel
maar ook niet altijd
Bram:
Ik wil shit maken, en die shit goed maken
Marc:
soms wil ik gewoon leijpe kkleijpe shit maken
Ik lees theory of fun
dus ik ben nu van mening dat alles een spelletje is
aangezien we er gewoon van leren
en het een andere manier iis van patroonherkenning
Bram:
Dat is wel een hele brede definitie van een spel
Marc:
hij geeft niet echt een definitie van game in die eerste hoofdstukken omdat dat er in feite niet toe doet, wat voor 1 iemand een game is, is voor iemand anders keiharde werkelijkheid
en daarnaast is hij van mening dat de games misschien wel dichter bij de werkelijkheid staan dan hoe wij de werkelijkeid waarnemen
omdat ons hoofd zoveel samenvoegt in patronen etc
vind ik wel mooi om te lezen
Bram:
Mja, maar is een game niet altijd fictie?
Marc:
nee niet dus
Bram:
Of in ieder geval een fictieve representatie van de werkelijkheid?
Marc:
omdat het ene kwestie is van patronen uit de werkelijkheid
ja maar gast
wij nemen de werkelijkheid niet eens waar zoals hij is, dus hoe kanje dan in den beginne al spreken van een nonfictieve representatie van de werkelijheid
die is er niet
wij nemen de werkelijkheid ook niet waar zoals hij is, dus zou je kunnen stellen dat onze werkelijkheid ook maar een spelletje is
Bram:
Mja, misschien. Maar een spel is iets waar je vrijwillig aan deelneemt
De werkelijkheid helaas niet
(Ja, tenzij je zelfmood meerekent)
Marc:
maar dat je er vrijwillig aan deelneemt wil nog niet zeggen dat het fictief is...
Bram:
Een spel heeft een kop en een staart.
Marc:
de werkelijkheid ook
Bram:
True, maar niet vrijwillig
Ik kan een spel beginnen wanneer ik wil
En eindigen wanneer ik wil
Het leven kan ik eindigen wanneer ik dat wil
Maar niet beginnen
En ik doe niet vrijwillig mee, maar omdat ik buiten zelfmoord geen keuze heb.
Marc:
nee hoor, je doet vaak genoeg mee aan het spel van iemand anders zonder dat je daarvoor gekozen hebt. Dan neem je het alleen waar als de werkeljkeid
Bram:
Voorbeeld?
Marc:
maar die persoon kan ghoed met iets bezig zijn wat voor hem een spelletje is en voo rjou bittere ernst
voorbeeld: hoe sommige mensen met elkaar omgaan. Ik weet dat ik als kind dingen wel eens zag als een spelletjes (hoe ik dan met mijn peers omging) maar omdat mijn omgeving dat niet wist is het vervolgens voo rhen de werkelijkheid
terwijl het nog steeds een spelletje is
maar als we hier te lang op doorghaan wordt het meer filosofische kwestie
Bram:
Hahaha, ja
Marc:
en ik moet nog een hoofdstukje lezen
Bram:
Kunst is het concreet houden
Anders slacht Karel je af
Marc:
ja idd
Bram:
Want nog even 1 punt
Hoewel jij dat spel speelde, koos je er zelf voor het te beginnen, en te eindigen. Zo gauw je 'medespeler' door heeft dat jij een spel speelt, kan hij de keuze maken mee te spelen of het te beïndigen.
Bram:
Hahaha
Filosofie staat alleen altijd in de weg van een concreet debat.
Marc:
nee is niet waar, ja trouwens misschien juist wel
Bram:
Het is denk ik ook maar net hoe je Game Design ziet
Marc:
ja zeker waar
Bram:
Ik zelf zie het als een ambacht. Iets concreets.
Anderen mensen, misschien jij ook, zien het filosofischer.
Marc:
en ik geloof niet dat welke vorm van design/kunst een ambacht is. Op het moment datje vormen van kunst als ambacht gaat zien, wordt het lopende band werk (niet letterlijk natuurlijk maar ik kon geen betere term verzinnen zo snel). Maar daarnaast ben ik wel weer van mening dat je kunst als iets concreets kunt zien, iets waar je formele regels aan kunt vasthangen. maar dan moet je die regels ook wel
weer kunnen doorbreken
maja, ik ga ff verder lezen en samenvatten
Bram:
Is goed man
Marc:
misschien moeten we dit msngesprek gewoon op de blog zetten
Bram:
Maar een ambacht zie ik meer als wat jij beschrijft
Juist -geen- lopende band werk.
Maar een werkvorm waarin creativiteit en formaliteit elkaar kruisen.
Marc:
nee, lopende band werk ws ook de evrkeerde term
Bram:
Maatwerk!
Marc:
jaaaa
das wel een goeie
Bram:
Bepaalde principes zijn overdraagbaar
Maar per 'klant' moet je creatief zijn.
Marc:
maar dan wel zo dat de creativiteit ondergeschikt is aan de formaliteit
Bram:
Juist.
Een hoefsmid maakt een hoefijzer. Altijd dezelfde vorm, hetzelfde principe, maar aangepast per paard.
Marc:
idd
maar dat wil ik dus niet met games
dat is voor mij een kunstvorm
Bram:
Ik dus wel
Marc:
een manier om me te uiten
ik ben me heel erg bewust van die formalitiet en ben heel erg bereid om me daar in te schikken olang ik hier op school zit
Bram:
Verschil in redenatie tussen creatie vanuit jezelf, en creatie voor een ander.
Marc:
ja zeker waar
Bram:
Ik rederneer vanuit het laatste. Ik heb geen boodschap
En ik wil de wereld niet verbeteren
Marc:
ikke wel
maar ook niet altijd
Bram:
Ik wil shit maken, en die shit goed maken
Marc:
soms wil ik gewoon leijpe kkleijpe shit maken
Rules to Play by: Story and Game Design
Games Telling stories?
-A brief note on games and narratives
by Jesper Juul
In this article Jesper Juul poses the following question: Do Games tell Stories?
To answer this question Juul examines three arguments that favor the statement that Games tell Stories. Then Jull switches sides and looks at three arguments that speak against this statement. Then he finishes by looking at some experimental ways of telling Stories in games.
The most compelling argument he looks at that favors Games telling Stories is the argument that we use narrative for everything. Our brain works best when we can create a context, even if that means we draw our own conclusions. Because of that, a game wouldn't even need to spell out a narrative to a player. Instead, the player will create a context and story in his own mind almost automatically.
Juul also describes some of the trouble with translating a Story to a Game, arguing that Story itself can only be presented through a medium. (Be it a book, movie, play or videogame.) However, when translating a story, or a linear experience to a game, some issues arise. Most notably that the player will always be active. He also argues that games are less proficient at using 'time' to their advantage. Whereas film, theater and literature can freely switch between tenses over the discourse of a story, games hardly do so. I can't say I agree with Juul here. Playing through a non-linear timeline, where the story switches between timelines, should prove the same problems as playing through a linear timeline. As Juul said, in games we play through events. Following that argument, it shouldn't matter if these events are offered to the player in a chronological fashion or not.
The last section of Juul's article admittedly confused me a little. It deals with avant-garde, experimental narratives, but he discusses these issues in such broad, general terms that it's hard to really see what he's getting at.
Game Design: From Blue Sky to Green Light
-Deborah Todd
Chapter 4: Story in Game Design -- The Thousand-Pound Gorilla
This is a 30 page chapter, mostly filled with interviews and observations from designers working for the larger studios. However, the first few pages of the chapter actually deal with Todd's views on Game Design, and on how story should be written for it. She starts off with an interesting point, arguing that no matter how you look at it, when you make a game, you tell a story. When you tell someone about a game you're making, you're telling its story. Who is the game about? What is the goal? What is the setting. According to Todd these characteristics are all related to story, and therefore, a game always has a story. I guess this all depends on your definition of story, but it's not one I would subscribe to myself. As Todd reasons, everything is story, which might be true, but that doesn't mean that story is also a narrative. Not every game is about a character, not every game is about a history, not every game is a series of sequential events.
Later on however, in a paragraph called "And then..." versus "And because..." She does make an interesting point but fails to truely come to a solid conclusion. While Todd argues that writing a story in an "And then this happened, and then that happened..." way is rather boring and shallow compared to a "And because of this happened that other thing happened" approach, she fails to point out whywhy this is. In my opinion, she makes a valid point in saying that the "and because" method makes for a more organic story, but she never says how this could be interesting for a good game design. As I see it, the "And then" approach is linear, more based on cinema and literature than anything. The "And Because" method would be a lot more practical for games as they give a reason as to why events unfold the way they do, allowing for variation and deviation from the linear path, as we can look at cause and effect.
When Designers Have Story Problems
-Jeff Spock
This Gamasutra article written by writer Jeff Spock lists five reasons why Designers shouldn't complain when story gets in the way of design. In short, he lists the following reasons:
1) The designers should have paid attention to the story earlier, and the fact that they have to change things is their own fault for not referring back to the story earlier.
2)The writer was put on the team too late, which is bad practice
3)Story, if done well, should be an instrumental part of the game. If this isn't the case, shame on the designers!
4)A writer understands that changes in design might ask for a change in story. Designers should understand that they are required to do the same when the story asks for it.
5)The story isn't just the writer's problem, it's the team's problem.
Now, when reading this, I have to say Mr Spock has some issues with priorities, at least in my opinion.
1)Perhaps they should have paid attention to the story earlier, if we assume the story is that important to the game.
2)Might be bad practice, but then again, if a writer is brought into the project this late in development, he can't really expect to go around changing aspects of the game that have already been produced.
3)If story is done well, it should be an important part of the design. That said, shouldn't the writer come up with something that matches the story rather than a designer having to accomodate the story in his game? This ofcourse all depends on the project itself, but in my opinion, story shoudl support design, not the other way around.
4)Pretty much the same as with point three. A writer should understand that he supports the game, not the other way around.
5)Very much so, but the writer is responsible for creating a story that fits within, and enforces the game design.
Conclusion
Alright, so at the end, what are my views on all of this? Where does story fit into games?
First of all, there's a matter of definition. Without defining what story means to me, it's hard to explain. To me, a story (within a game) is a sequence of narrative events (using characters, backstory and setting) that is driven by the actions of a player.
Not every game demands a story. Some games are perfectly fine relying just on gameplay mechanics and form. Games like Tetris don't need a story, and to a game like Castle Crashers story is mostly inconsequential and not instrumental to the final design.
Then there are games that use story. For example, take Mass Effect. But even then, a designer needs to be constantly aware of the fact that story is just another button to push and trigger an experience with the player, much like form does.
Keeping that in mind, story should always be written as a design, it should adhere to the same rules as game design does, meaning that it needs -function-. If a story isn't functional, if it isn't used as a 'button' to press, get rid of it. It doesn't matter anymore and you might just as well leave it out.
So in conclusion: Yes, story can be used succesfully as a button to push, as Mass Effect shows, but it can never be reason for making a game, nor can one expect a design to support a narrative.
-A brief note on games and narratives
by Jesper Juul
In this article Jesper Juul poses the following question: Do Games tell Stories?
To answer this question Juul examines three arguments that favor the statement that Games tell Stories. Then Jull switches sides and looks at three arguments that speak against this statement. Then he finishes by looking at some experimental ways of telling Stories in games.
The most compelling argument he looks at that favors Games telling Stories is the argument that we use narrative for everything. Our brain works best when we can create a context, even if that means we draw our own conclusions. Because of that, a game wouldn't even need to spell out a narrative to a player. Instead, the player will create a context and story in his own mind almost automatically.
Juul also describes some of the trouble with translating a Story to a Game, arguing that Story itself can only be presented through a medium. (Be it a book, movie, play or videogame.) However, when translating a story, or a linear experience to a game, some issues arise. Most notably that the player will always be active. He also argues that games are less proficient at using 'time' to their advantage. Whereas film, theater and literature can freely switch between tenses over the discourse of a story, games hardly do so. I can't say I agree with Juul here. Playing through a non-linear timeline, where the story switches between timelines, should prove the same problems as playing through a linear timeline. As Juul said, in games we play through events. Following that argument, it shouldn't matter if these events are offered to the player in a chronological fashion or not.
The last section of Juul's article admittedly confused me a little. It deals with avant-garde, experimental narratives, but he discusses these issues in such broad, general terms that it's hard to really see what he's getting at.
Game Design: From Blue Sky to Green Light
-Deborah Todd
Chapter 4: Story in Game Design -- The Thousand-Pound Gorilla
This is a 30 page chapter, mostly filled with interviews and observations from designers working for the larger studios. However, the first few pages of the chapter actually deal with Todd's views on Game Design, and on how story should be written for it. She starts off with an interesting point, arguing that no matter how you look at it, when you make a game, you tell a story. When you tell someone about a game you're making, you're telling its story. Who is the game about? What is the goal? What is the setting. According to Todd these characteristics are all related to story, and therefore, a game always has a story. I guess this all depends on your definition of story, but it's not one I would subscribe to myself. As Todd reasons, everything is story, which might be true, but that doesn't mean that story is also a narrative. Not every game is about a character, not every game is about a history, not every game is a series of sequential events.
Later on however, in a paragraph called "And then..." versus "And because..." She does make an interesting point but fails to truely come to a solid conclusion. While Todd argues that writing a story in an "And then this happened, and then that happened..." way is rather boring and shallow compared to a "And because of this happened that other thing happened" approach, she fails to point out whywhy this is. In my opinion, she makes a valid point in saying that the "and because" method makes for a more organic story, but she never says how this could be interesting for a good game design. As I see it, the "And then" approach is linear, more based on cinema and literature than anything. The "And Because" method would be a lot more practical for games as they give a reason as to why events unfold the way they do, allowing for variation and deviation from the linear path, as we can look at cause and effect.
When Designers Have Story Problems
-Jeff Spock
This Gamasutra article written by writer Jeff Spock lists five reasons why Designers shouldn't complain when story gets in the way of design. In short, he lists the following reasons:
1) The designers should have paid attention to the story earlier, and the fact that they have to change things is their own fault for not referring back to the story earlier.
2)The writer was put on the team too late, which is bad practice
3)Story, if done well, should be an instrumental part of the game. If this isn't the case, shame on the designers!
4)A writer understands that changes in design might ask for a change in story. Designers should understand that they are required to do the same when the story asks for it.
5)The story isn't just the writer's problem, it's the team's problem.
Now, when reading this, I have to say Mr Spock has some issues with priorities, at least in my opinion.
1)Perhaps they should have paid attention to the story earlier, if we assume the story is that important to the game.
2)Might be bad practice, but then again, if a writer is brought into the project this late in development, he can't really expect to go around changing aspects of the game that have already been produced.
3)If story is done well, it should be an important part of the design. That said, shouldn't the writer come up with something that matches the story rather than a designer having to accomodate the story in his game? This ofcourse all depends on the project itself, but in my opinion, story shoudl support design, not the other way around.
4)Pretty much the same as with point three. A writer should understand that he supports the game, not the other way around.
5)Very much so, but the writer is responsible for creating a story that fits within, and enforces the game design.
Conclusion
Alright, so at the end, what are my views on all of this? Where does story fit into games?
First of all, there's a matter of definition. Without defining what story means to me, it's hard to explain. To me, a story (within a game) is a sequence of narrative events (using characters, backstory and setting) that is driven by the actions of a player.
Not every game demands a story. Some games are perfectly fine relying just on gameplay mechanics and form. Games like Tetris don't need a story, and to a game like Castle Crashers story is mostly inconsequential and not instrumental to the final design.
Then there are games that use story. For example, take Mass Effect. But even then, a designer needs to be constantly aware of the fact that story is just another button to push and trigger an experience with the player, much like form does.
Keeping that in mind, story should always be written as a design, it should adhere to the same rules as game design does, meaning that it needs -function-. If a story isn't functional, if it isn't used as a 'button' to press, get rid of it. It doesn't matter anymore and you might just as well leave it out.
So in conclusion: Yes, story can be used succesfully as a button to push, as Mass Effect shows, but it can never be reason for making a game, nor can one expect a design to support a narrative.
Rules to Play by: Figuring out who I am as a designer
I guess a problem many people face when studying anything design-related is trying to figure out where they stand in the grand scheme of things. I certainly know I do, and many of my fellow students experience the same.
Going into Game Design I figured I knew a lot, a bubble that was quickly popped in the first year, which left me with more questions than answers. A sure sign that I'm learning for sure, but now the time has come to try an figure out where I'm headed and where I want to be.
So where does that leave me? Well, it leaves me with a weekly assignment handed to me and my fellow classmates by one of our teachers. Every week I'll be reading three articles or chapters about Game Design, or Design in general. I'll give my personal view on every article, hoping that eventually I'll be able to write a short paper on my personal views as a Game Designer.
Every week I'll try to pick a different subject to read about. To kick it all off, I'll read articles about one of the bubbles that was popped last year. Story in games. Story in Game Design is a topic I completely changed my views on in the past year, making it an easy jump-off point while I try to figure out a proper format for this assignment.
Going into Game Design I figured I knew a lot, a bubble that was quickly popped in the first year, which left me with more questions than answers. A sure sign that I'm learning for sure, but now the time has come to try an figure out where I'm headed and where I want to be.
So where does that leave me? Well, it leaves me with a weekly assignment handed to me and my fellow classmates by one of our teachers. Every week I'll be reading three articles or chapters about Game Design, or Design in general. I'll give my personal view on every article, hoping that eventually I'll be able to write a short paper on my personal views as a Game Designer.
Every week I'll try to pick a different subject to read about. To kick it all off, I'll read articles about one of the bubbles that was popped last year. Story in games. Story in Game Design is a topic I completely changed my views on in the past year, making it an easy jump-off point while I try to figure out a proper format for this assignment.
Abonneren op:
Posts (Atom)
