Having spent the past few weeks revising my graduation project proposal, I thought it would be a good idea to post how things were at this time.
As things stand now, I will be focussing on streamlining the development of exploratory prototypes. This means improving efficiency of idea generation and design translation to development, and in turn improving the relationship between initial idea and eventual implementation.
The idea is to abstract existing creative techniques, and heuristics extracted from the creative process of designers, to a limited amount of influences on the designer's thought process.
A Quick review of the steps during a creative process and the parts that I will be focussing on.
Phase 1 - The Problem
Phase 2 - The Ideas
Phase 3 - Evaluation
Phase 4 - Selection
Game design as a creative field is unique in the respect that the Problem and the Ideas both share a common origin: The Game Designer. Because of this, I will not be dealing as much with the problem area. Instead, I will choose a set of common starting points (themes, proven concepts, etc) and use those as the "problem space".
My project will deal more with the development of ideas during the idea phase, and how to evaluate them to develop 'good' ideas. This valorisation is, of course, very subjective which is why it will be based around design goals setup during the problem phase.
Well, back to work!
woensdag 27 februari 2008
vrijdag 15 februari 2008
Structural Innovation
After speaking to my peers for some time, I realized something that was actually very obvious: Game Design as a task is split into two main factors.
1. Coming up with a concept
2. Specifying and Communicating this concept through a Design Document
There's a plethora of research, information and established methodologies for 2. However, the former is a lot less established. Throughout my education, I've only come into contact with methods of creativity that primarily used brainstorming or random association techniques. However, brainstorming is often arduous and inefficient- depending heavily on group dynamics, whereas I've found random association mostly useless to a field as specific as games.
Where am I going with this?
I guess what I'm trying to convey is that there is a lack of structure to the creative process of game design. Most concept development relies entirely on the creativity of the individual, which usually means sporadic development of new (and good) ideas. Perhaps the current state of affairs can be explained via the following:
To come up with a concept you start at point A, and need to traverse B and C to get to D. Highly creative individuals can skip B and C and go straight to D. However, this doesn't mean they have achieved the best possible path to D and it's to be expected that the ideas generated will be personally biased (which can be both good and bad) Also, less creative individuals might get stranded at B or C and produce mediocre ideas.
A technique by Edward D. Tauber called Heuristic Ideation Technique (HIT) proposes a formalization of the creativity process, which he illustrates with examples from the food industry. In this technique, you would identify all relevant factors to a domain and examine combinations. However, applying this approach to game design will differ in one fundamental aspect: relevant factors are not bound to reality. Game designers can come up with literally anything, whereas food product designers cannot.
What I'm currently proposing to research, is the use of semantic heuristics to produce structural innovation at a constant rate, using existing (proven) ideas and altering their function to stimulate creative use of their relevant factors. Obviously, this still requires creativity from the individual to read the new possible contexts of the altered functionality, but this level of creativity is considerably less intense than before.
1. Coming up with a concept
2. Specifying and Communicating this concept through a Design Document
There's a plethora of research, information and established methodologies for 2. However, the former is a lot less established. Throughout my education, I've only come into contact with methods of creativity that primarily used brainstorming or random association techniques. However, brainstorming is often arduous and inefficient- depending heavily on group dynamics, whereas I've found random association mostly useless to a field as specific as games.
Where am I going with this?
I guess what I'm trying to convey is that there is a lack of structure to the creative process of game design. Most concept development relies entirely on the creativity of the individual, which usually means sporadic development of new (and good) ideas. Perhaps the current state of affairs can be explained via the following:
To come up with a concept you start at point A, and need to traverse B and C to get to D. Highly creative individuals can skip B and C and go straight to D. However, this doesn't mean they have achieved the best possible path to D and it's to be expected that the ideas generated will be personally biased (which can be both good and bad) Also, less creative individuals might get stranded at B or C and produce mediocre ideas.
A technique by Edward D. Tauber called Heuristic Ideation Technique (HIT) proposes a formalization of the creativity process, which he illustrates with examples from the food industry. In this technique, you would identify all relevant factors to a domain and examine combinations. However, applying this approach to game design will differ in one fundamental aspect: relevant factors are not bound to reality. Game designers can come up with literally anything, whereas food product designers cannot.
What I'm currently proposing to research, is the use of semantic heuristics to produce structural innovation at a constant rate, using existing (proven) ideas and altering their function to stimulate creative use of their relevant factors. Obviously, this still requires creativity from the individual to read the new possible contexts of the altered functionality, but this level of creativity is considerably less intense than before.
zaterdag 9 februari 2008
Innovation?
I've been going back and forth between a lot of people and talking to them about my prospective research topic, and it kept coming back to a question of relevance. Sure, it's a fascinating research topic, but its use to anybody other than myself is negligible. I've thus decided to move up one layer of abstraction on what I was actually doing.
So, what was I doing? I had this idea that time could be used in fascinating ways for game design. And after I had developed some mechanics that could work, I came across a game that was already using them: Braid. This 2D platform game by Jon Blow uses most of the reverse time & doubling yourself mechanics that I had thusfar come up with.
Here's a video of a very interesting lecture by Jon Blow
So, back to what I was doing. Simply put, I was trying to do something new and I wanted to find out a way that I could somehow structure that process. The process of figuring out what to do that was new. Of course I have a pretty clear direction of what I want, which is "something to do with time". However, the question of how to structure such an idea into a process to come up with something new is a lot more interesting.
As far as relevance goes, there are a lot of questions surrounding this new buzzword "innovation". First of all, what is innovation? And secondly, is that anywhere near what we imply when we use it as a buzzword?
So, what was I doing? I had this idea that time could be used in fascinating ways for game design. And after I had developed some mechanics that could work, I came across a game that was already using them: Braid. This 2D platform game by Jon Blow uses most of the reverse time & doubling yourself mechanics that I had thusfar come up with.
Here's a video of a very interesting lecture by Jon Blow
So, back to what I was doing. Simply put, I was trying to do something new and I wanted to find out a way that I could somehow structure that process. The process of figuring out what to do that was new. Of course I have a pretty clear direction of what I want, which is "something to do with time". However, the question of how to structure such an idea into a process to come up with something new is a lot more interesting.
As far as relevance goes, there are a lot of questions surrounding this new buzzword "innovation". First of all, what is innovation? And secondly, is that anywhere near what we imply when we use it as a buzzword?
woensdag 6 februari 2008
Case Studies
To investigate what has already been done with time in games, I chose to do case studies on two games: Timeshift and Blinx 2: Masters of Time. These two games feature two different genres (First Person Shooter and Third Person Puzzle/Action) and Blinx, being a bit older, is expected to have fundamentally different implementations.
Let's start with Blinx. What immediately surfaces is the causal nature of the feature in relation to the level design. Most of your time powers (reverse, slow, pause, forward & record) are only useful in specific level design applications. This leads me to define these implementations as "specific" implementations. However, the slow feature is more generically applicable, as it simply stops everything and allows you to do more than one thing with the given time. Also, it is the only power I chose to use in emergencies, which usually meant iminent death by enemy incursion.
So, this leads me to define the opposite end of the spectrum as "generic" implementations. By generic, I mean that they can always be used and that their effect will always be present, without a required predetermined solution being placed in proximity to the player. Blinx clearly chose to implement the feature in a specific fashion, possibly hindered by technical implementation difficulties for generic features.
Now let's take a look at Timeshift. Timeshift uses only generic implementations, meaning that the player has access to them at all times and their effects are always noticeably present. However, they're not always as useful. This is why they also chose to use their generic implementations in specific ways.
The best example of the use of the Time Stop generic feature in a specific way, is in physics puzzles. During time stop, the player can walk on water and nothing will perform physics updates. So, if the player leverages an object upwards, then stops time, and walks across it, he will be able to get up to higher places. This is used a few times in the first few levels of the game.
Another specific implementation of a generic feature is the time reverse feature. In the first level of Timeshift, the player has to run across a suspended hallway, which crumbles right before the player is able to get to it (which is a scripted event). The player then has to activate the time reverse feature in order to be able to get through the hallway before it collapses.
An interesting observation of both singleplayer portions of the games is that all time features are user-centered, meaning the user initiates them and is the centre of all time features. It is also possible, of course, to implement non user-centered features, such as time dilation fields in a level. These could be used in a very interesting fashion for puzzles, where the goal of the user could be: "Get to the finish line before the race starts!".
This still entails that time is a global constant, however. What if time was not a global constant, and you could have different pockets of time progression across a level. For instance, a time reversed pocket would have everything happen in reverse order, without affecting anything happening outside of it. A very easy way to be able to finish before you started would thus simply be to put the clock used to check time into a time-reverse pocket.
Timeshift uses this with their time-grenades in multiplayer. Player can throw reverse/slow/stop grenades and these have expected results. However the reverse grenade takes some getting used to, as it simply fires back any objects entering into it, including players. Their implementation doesn't really feel like you're playing with time, however, and mostly feels like an existing concept has been re-explained using time.
The only novel feature is time-stop. Time slow is obviously slow-motion, which makes performing skill-based actions, like shooting at a moving target, easier to perform. In this case only certain areas of the game are slowed down, making the outside a favourable position. Time-reverse is the least novel, because it's basically a deflection shield. It just shoots everything back, disregarding any relation between spacetime and momentum, which makes it lose any real link it had to time.
Let's start with Blinx. What immediately surfaces is the causal nature of the feature in relation to the level design. Most of your time powers (reverse, slow, pause, forward & record) are only useful in specific level design applications. This leads me to define these implementations as "specific" implementations. However, the slow feature is more generically applicable, as it simply stops everything and allows you to do more than one thing with the given time. Also, it is the only power I chose to use in emergencies, which usually meant iminent death by enemy incursion.
So, this leads me to define the opposite end of the spectrum as "generic" implementations. By generic, I mean that they can always be used and that their effect will always be present, without a required predetermined solution being placed in proximity to the player. Blinx clearly chose to implement the feature in a specific fashion, possibly hindered by technical implementation difficulties for generic features.
Now let's take a look at Timeshift. Timeshift uses only generic implementations, meaning that the player has access to them at all times and their effects are always noticeably present. However, they're not always as useful. This is why they also chose to use their generic implementations in specific ways.
The best example of the use of the Time Stop generic feature in a specific way, is in physics puzzles. During time stop, the player can walk on water and nothing will perform physics updates. So, if the player leverages an object upwards, then stops time, and walks across it, he will be able to get up to higher places. This is used a few times in the first few levels of the game.
Another specific implementation of a generic feature is the time reverse feature. In the first level of Timeshift, the player has to run across a suspended hallway, which crumbles right before the player is able to get to it (which is a scripted event). The player then has to activate the time reverse feature in order to be able to get through the hallway before it collapses.
An interesting observation of both singleplayer portions of the games is that all time features are user-centered, meaning the user initiates them and is the centre of all time features. It is also possible, of course, to implement non user-centered features, such as time dilation fields in a level. These could be used in a very interesting fashion for puzzles, where the goal of the user could be: "Get to the finish line before the race starts!".
This still entails that time is a global constant, however. What if time was not a global constant, and you could have different pockets of time progression across a level. For instance, a time reversed pocket would have everything happen in reverse order, without affecting anything happening outside of it. A very easy way to be able to finish before you started would thus simply be to put the clock used to check time into a time-reverse pocket.
Timeshift uses this with their time-grenades in multiplayer. Player can throw reverse/slow/stop grenades and these have expected results. However the reverse grenade takes some getting used to, as it simply fires back any objects entering into it, including players. Their implementation doesn't really feel like you're playing with time, however, and mostly feels like an existing concept has been re-explained using time.
The only novel feature is time-stop. Time slow is obviously slow-motion, which makes performing skill-based actions, like shooting at a moving target, easier to perform. In this case only certain areas of the game are slowed down, making the outside a favourable position. Time-reverse is the least novel, because it's basically a deflection shield. It just shoots everything back, disregarding any relation between spacetime and momentum, which makes it lose any real link it had to time.
vrijdag 1 februari 2008
Random Thoughts
In Portal, users create portals to shorten the length between two points and thus diminish the amount of time it will take them to reach these places, but also to remove any obstacles that might be between these two points preventing players from reaching them normally. The interesting thing about this is that it does not distort the time-space relationship. It merely allows the user to bypass sections of it. Maybe the idea is to do the same with time. Distort the reality of time, but still uphold its relation to space.
What if, for instance, instead of a portal being a window between two points, the portal was a window between two times. Let's say the player can spawn a portal on a wall, and when the user walks through this portal, he/she is transported back a fixed amount of time. The user can then choose to readily switch between timezones by entering the portal.
Or, perhaps it can be interesting for time dilation to be a factor in game mechanics. What if time moves slower or backwards between certain areas. You could use this to your advantage when attempting to solve puzzles or plant traps for oncoming enemies.
The hardest thing to do in these concepts is to clearly split the timezones for the player, whilst maintaining a connection of causality. It might be disturbing to the player to do something in the past that does not leave any trails in the future, however, when in the past one does not want to see the things he/she did in the future.
The most interesting thing I've created so far is a simple example of how time dilation can influence irregular systems. Take flocking, for example. I was testing to see if I could create time dilation (making things move slower in relation to their distance to the mouse-cursor, in this case) and applied it to a flocking algorithm I had in flash. The interesting result was that this allowed me to guide their direction, as I could intentionally slow the movement of specific parts of their group. Since flocking is based on group movement, this lead to the other entities of the group to move back more towards the units I had slowed down, which was something I hadn't intended to do.
I'm hoping the same emergence can be triggered in playtesting of specific features to allow the design of the feature to further develop.
What if, for instance, instead of a portal being a window between two points, the portal was a window between two times. Let's say the player can spawn a portal on a wall, and when the user walks through this portal, he/she is transported back a fixed amount of time. The user can then choose to readily switch between timezones by entering the portal.
Or, perhaps it can be interesting for time dilation to be a factor in game mechanics. What if time moves slower or backwards between certain areas. You could use this to your advantage when attempting to solve puzzles or plant traps for oncoming enemies.
The hardest thing to do in these concepts is to clearly split the timezones for the player, whilst maintaining a connection of causality. It might be disturbing to the player to do something in the past that does not leave any trails in the future, however, when in the past one does not want to see the things he/she did in the future.
The most interesting thing I've created so far is a simple example of how time dilation can influence irregular systems. Take flocking, for example. I was testing to see if I could create time dilation (making things move slower in relation to their distance to the mouse-cursor, in this case) and applied it to a flocking algorithm I had in flash. The interesting result was that this allowed me to guide their direction, as I could intentionally slow the movement of specific parts of their group. Since flocking is based on group movement, this lead to the other entities of the group to move back more towards the units I had slowed down, which was something I hadn't intended to do.
I'm hoping the same emergence can be triggered in playtesting of specific features to allow the design of the feature to further develop.
Switch
I've decided to switch subject, due to the following: In the EMMA Graduation Project setup, the project part, as opposed to the "supportive narrative" ("thesis") part, is valued as more important. So, the supportive narrative, as its name implies, should support the project. Not the other way around. Since I'm a very theoretical person by nature, this was a hard thing for me to do.
However, I did have a very clear idea of what I wanted to do for the project: Design and implement a time-travel feature (most likely in the Source Engine)
My choice of subject is now entirely based on my desire to design and implement this feature, so I came up with a supportive narrative that I could accomplish with a research through design method: evolutionary design.
Basically, I'm going to create prototypes of the feature, and have these prototypes extensively tested. Based on these tests, user feedback and peer review input I'm going to adapt the feature to a version that allows for more interesting gameplay to be created.
Finally, I hope to deliver an implementation that offers a high content of gameplay diversity.
However, I did have a very clear idea of what I wanted to do for the project: Design and implement a time-travel feature (most likely in the Source Engine)
My choice of subject is now entirely based on my desire to design and implement this feature, so I came up with a supportive narrative that I could accomplish with a research through design method: evolutionary design.
Basically, I'm going to create prototypes of the feature, and have these prototypes extensively tested. Based on these tests, user feedback and peer review input I'm going to adapt the feature to a version that allows for more interesting gameplay to be created.
Finally, I hope to deliver an implementation that offers a high content of gameplay diversity.
Abonneren op:
Posts (Atom)