Coming along

I've been very busy lately, so I haven't updated much.

I've updated the reference model, as well as selected and finished a feature for the third step in the process, which has three defined phases:

Diverging
In this phase the designer uses creative techniques to break beyond his own patterns and structures.

Converging
In this phase the reference model allows the designer to relate his ideas to games in general, to fill in blanks and to adapt what he has into an actual game.

Development
Since the process focuses on programmers that are also experienced in game design, the last step is made especially for software prototyping. It is basically a library that can be linked to the existing game, which will allow the immediate tweaking of game variables. Wouldn't it be great, for instance, to edit the height that you can jump without having to go back and recompile?

Anything's possible, but currently the library is dependent on DirectX 9 and Windows because I haven't the time to make it cross-platform. Maybe later ;)

Here's a video of the feature in action. I'll also upload some gameplay specific examples later, but since I already had particle emitters this was the easiest one to do right away.



You can also download the video here

Another great source of information I've come across, to support the validity of the process I'm using and in fact to inspire the choice and combination of creative techniques employed, is cognitive psychology. If you're interested in creativity I suggest take a look at his website.

I've also come across the doctoral dissertation of Matti Kalevi Perttula, who did research on creativity for engineering design. This can be found here, and I especially suggest reading the third chapter, Related Studies, for the in depth history on existing research it offers.

Early Prototype

Here's a video of an early version of the first game prototype, built with my very own engine. It supports particle effects, untextured models and audio, which is more than enough for now.

First Prototype - Video 1

About the model

Through the project and research I'm doing, I'm setting up a methodology for short single-iteration prototyping projects.

The properties are currently:

• Provide a situation in which the designer can judge the viability of an idea after a single prototype cycle. (ideal)
  
• Streamline creativity and allow for a faster concept & development cycle.
  

And has the following requirements:

• The method may not reduce the overall ‘depth’ of the creative process.

The method is largely devided into three sections: Diverging, Converging and Constructing.

After attempting to construct a prototype through the use of what ideas I had of the convergence model, I've been able to refine it to a reasonable state. Currently, the process of convergence relies on taking the ideas from the divergent phase, which can be pretty abstract, and relating them to an abstract representation of games to ensure a game-structure quickly and easily emerges.

The model of games is split, for the time being, into the following parts:

• Form
• Functional
• Fictional
• System
• Elements
• Active
• Passive
• Conditions & Responses

(note that this makes no mention of the player and how she interacts with the system yet)

Form deals with anything that is perceived by the player’s senses. This means anything visual, auditory, haptic, etc can be considered ‘form’. Especially visual game artists decribe two distinct versions of it: functional and fictional art. The distinction is that a functional description describes what something is or is doing, whereas a fictional description adds to the former a layer of representation. Note that this means the two are not mutually exclusive.

System contains everything that makes the game interactive. It accepts input from the player and provides output, which is described as form. Core Techniques and Algorithms for Game Design provided a very interesting distinction between elements found in the system. These are ‘passive’ and ‘active’ elements. I've chosed to define these as follows.

Passive elements are things that are in the game world, but don’t contribute directly to any interactivity. They may, however, influence other things that are active/passive.

Active elements are things that exhibit behavior. Usually it is these elements that cause the game to require input from the player. Take for instance pong, where the active ‘ball’ element threatens to leave the passive ‘field’ element. The player is required to react to this to prevent herself from losing.

Another fundamental part of the system in this model would be conditions. Conditions are descriptions of the ‘state of the game’ or any subset of it, which when met will elicit a response. This response can be valorized as either negative or positive to the player. As in the example earlier, when the ball leaves the field, the ball being outside of the field is a condition, which when met will elicit the response of points being awarded, either to the player or her opponent depending on where the ball leaves the field.

I've been busy building a small engine for the prototypes over the last month, so I'll post some screenshots of the first prototype soon. I've used the first cycle mostly to define the exact parameters and how to evaluate a possible outcome.

Along the way I found a very interesting blog I think everybody should look at, which is the blog of Annakaisa Kultima, a (game) researcher at the university of Tampere.

AaKoo’s Game Lab


It contains a lot of interesting information on creativity, including the following presentation about creative techniques (held at the GDC)

| Upload your own

The problem with game design

I've been studying creative techniques, and the biggest issue when translating them to game design is that they usually deal with problems. Game design doesn't, at least not on the level of the game designer. The product we make contains problems and tools to achieve solutions, but our design of the game cannot be abstracted to a problem.

So far I've found that creative techniques that, aside from inspiring creative thinking, demand the designer to specify a domain or system of properties (of a concept) allow to be used in game design more easily than others. I think this is mostly due to the need for specification of a concept direction, once a basic theme or starting point has been chosen. Moreover, I think concepts that do both (inspire creativity WHILE specifying the concept domain) are most potent for game design.

Levels of Abstraction

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!

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.

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?

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.

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.

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.

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.