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?
zaterdag 9 februari 2008
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.
dinsdag 29 januari 2008
Start
This blog is going to be an outside face of my "thesis" research for my personal graduation project for the Utrecht School of the Arts, EMMA program.
Currently, I've decided my topic is going to be about managing player expectations and mental models, and using them in such a way as to reintroduce existing content in a new way to provide players with an interesting and mind-opening experience.
Exactly what role the interpretation of these expectations will be and how they can be used is still unclear, but I know the direction is in this field.
Currently, I've decided my topic is going to be about managing player expectations and mental models, and using them in such a way as to reintroduce existing content in a new way to provide players with an interesting and mind-opening experience.
Exactly what role the interpretation of these expectations will be and how they can be used is still unclear, but I know the direction is in this field.
Abonneren op:
Posts (Atom)