Player - Avatar Symbiosis

In a recently released paper, Jeroen D. Stout (creator of Dinner Date) proposes an interesting theory on the relashionship between player and avatar. It is related to the things that have been discussed previous post about immersion, so I felt it was relevant to bring it up. The full paper can be gotten from here. I will summarize the ideas a bit below, but I still suggest all to read the actual paper for more info!

Most modern theorists of the mind agree that it is not single thing, but a collection of processes working in unison. What this means is that there is no exact place where everything comes together, but instead the interaction between many sub-systems give rise to what we call consciousness. The most clear evidence of this is in split brain patients, where the two brain-halves pretty much form two different personalities when unable to communicate.

This image of a self is a not fixed thing though and it is possible to change. When using a tool for a while it often begins to feel like an extension of ourself, thus changing ones body image. We go from being "just me" to be being "me with hammer". When the hammer is put down, we return to the old previous body image of just being "me". I have described an even clearer example of this in a previous post, where a subject perceives a sense of touch as located at a rubber hand. Research have shown that this sort of connection can get quite strong. If one threatens to drop a heavy weight or similar on the artificial body part (eg the rubber hand), then the body reacts just like it would to any actual body part.

What this means for games is that it is theoretically possible for the player form a very strong bond with the avatar, and in a sense become the avatar. I discuss something similar in this blog post. What Jeroen now purposes is that one can go one step further and make the avatar autonomously behave in a way that the players will interpret has their own will. This is what he calls symbiosis. Instead of just extending the body-image, it is the extension of the mind. Quite literally, a high level of symbiosis means that part of your mind will reside in the avatar.

A simple example would be that if player pushes a button, making the avatar jump, players feel as if they did the jumping themselves. I believe that this sort of symbiosis already happens in some games, especially noticeable when the avatar does not directly jump but has some kind of animation first. When the player-avatar symbiosis is strong this sort of animation does not feel like some kind of cut scene, but as a willed action. Symbiosis does not have to be just about simple actions like jumping though, but can be more complex actions, eg. assembling something, and actions that are not even initiated by the player, eg. picking up an object as the player pass by it. If symbiosis is strong then the player should feel that "I did that" and not "the avatar did that" in the previous examples. The big question is now how far we can go with this, and Jeroen suggests some directions on how to research this further.

Having more knowledge on symbiosis would be very useful to make the player feel immersed in games. It can also help solving the problem of inaccurate input. Instead of doing it the Trespasser way and add fine-control for every needed body joint, focus can lie on increasing the symbiosis and thus allowing simply (or even no!) input be seen by players as their own actions. This would make players feel as part of a virtual world without resorting to full-body exo-skeletons or similar for input. Another interesting aspect of exploring this further is that it can perhaps tell us something about our own mind. Using games to dig deeper into subjects like free will and consciousness is something I feel is incredibly exciting.

Peter Akrill: Travellers Tales, Codemasters

Position: Programmer
Worked on: Bionicle Heroes, LEGO Star Wars, LEGO Indiana Jones

Peter graduated from Bolton University in 2005, getting a First. His lecture was about the programming side of the industry. While I’m not a programmer, I found it interesting to see how they contribute to a game, how they operate in a studio and the problems they encounter.

While his lecture was mostly about programming, he did give some very sage advice about game content. He explained that players will notice a poorly finished feature in games, but they won’t notice a missing feature. He stressed the importance of polishing existing features before adding new ones.

An unexpected part of his lecture was how to stay healthy during crunch times. He told us to expect stress and long working hours during these times, and gave us some great advice on staying positive and healthy, advice which I will surely use myself.

Tech feature: Light Masking

So just wanted to give a quick info on a brand new feature: light box masks.

When placing lights in some rooms, it is common that light bleeds through walls, and show up in other rooms close by. The obvious way to fix this is to add shadows, but shadows can be pretty expensive (especially for point lights), so it is not often a viable solution. In Amnesia we solved this through careful placement, yet bleeding can be seen in some places.

To fix this I added a new feature that is able to limit the lights range with a box. This way the light can cast light as normal but is cut off before reaching an adjacent area. This pretty much does the job of shadows, but is much cheaper.

It turned out to be pretty simple to implement as well. In the renderer, different geometrical shapes are used to render lights (spheres for point lights and pyramids for spots) which make sure the light only affects needed pixels. To implement the masking, these shapes where simply exchanged for a box and then with some small shader changes it all worked.

Without masking:

With mask:

Dig Dug 1500 Word Review WIP

Introduction

Dig Dug is a 2D Pacman-esque movement based game, developed and published by Namco in 1982. The premise of the game is for the player to dig tunnels into the terrain to gain access to enemies. The player must kill all the enemies in a level, using a bicycle pump, to advance to the next level. The game ends when the player loses all of their stored lives.

Game Mechanics

Dig Dug has many different game mechanics that influence the game. Below I have listed each game mechanic, given it a description and then discussed if I think it is a positive or negative aspect of the gameplay.

Digging

Digging is the primary method of moving in Dig Dug. Whenever the player moves underground, they automatically dig. In the player can dig in 4 directions, up, down, left and right. They cannot dig diagonally.

Rocks

Each level in Dig Dug contains large rocks that can be used as weapons against the two types of enemy. If the player tunnels under a rock, it will begin to tremble, and after a few seconds will fall downwards, destroying all terrain and enemies underneath it. The player gets a score bonus when they kill enemies by using the rocks, more on this in the score section.

Enemies

In Dig Dug there are only two types of enemy, the Pooka and the Fygar.

The Pooka is the basic enemy in Dig Dug. It moves through tunnels that the player has created and attempts to kill them by running into them.

The Fygar is a green dragon-like creature. It has the ability to breath a deadly, ranged streak of fire, which passes through terrain. If the player comes into contact with the fire or touch the Fygar directly, they will perish and lose a life.

Both the Pooka and the Fygar have the interesting ability to turn into a pair of evil yellow eye ghosts and float through solid terrain. This allows the enemies to reach and attack the player, even if they haven't dug a tunnel directly to the monsters.

Bicycle Pump

The Bicycle Pump is the primary means of destroying enemies available to the player. Once the fire button is pressed, the pump will fire directly towards the direction the player is facing. If the pump hits an enemy then the player must press the fire button 4 times in quick succession to fully inflate and kill the enemy. If the player pauses during this process, the enemy will quickly deflate, regain movement, and attack the player.

Levels

Dig Dug uses a simple level structure,

Each level in Dig Dug is divided into four coloured sections. These colours represent how deep underground the player has ventured. The deeper underground the player is when they kill an enemy, the larger point bonus they receive.

The game shows both a visual and text based representation of which level the player is on.

 

Score

Dig Dug features a score system that gives the player points for; killing enemies, digging through terrain and collecting fruit pickups. The player gets additional points if they dig under a rock and use it to crush pursuing enemies.

Dig Dug uses a high score system to remember the highest score the player has reached before dying. This score is permanently stored in the games memory, and is shown on the screen at all times. This prompts the player to try and beat their best score.

Lives

Dig Dug uses a simple lives system. The player begins the game with 3 lives, and gains an additional life every time their score increases by 10000. The player loses a life if they collide with; a Pooka, Frygar, Frygar fire, or a falling rock. When the player loses all of their lives, a game over occurs, and the player is sent back to the main menu screen.

Now I have described the basic mechanics of Dig Dug, I will discuss how these mechanics shape the game.

FADT (Formal Abstract Design Tools) (Church Doug, 1999, Page 3), can be used to break a game down into tools. Church finds three useful tools when analysing Super Mario 64, intention, perceivable consequence, and story. All three of these tools can be applied to Dig Dug to analyse the game and its mechanics.

Intention

Intention is the act of the "player making an implementable plan of their own, created in response to the current situation in the game world and one's understanding of the game play options.". (Church Doug, 1999, Page 4). When a player plays Dig Dug they must create a plan of action if they hope to achieve victory over each individually level in the game. This plan of action will change depending on: how many lives the player has remaining, the position and number of enemies on the screen and the pathway of tunnels dug through the terrain. The player must analyse all of these constantly changing game elements and make a plan to respond to the situation.

Dig Dug by its nature, is a fast, cruel game. One moment the player can be setting a new high score and have 3 lives remaining, the next, 2-3 enemies can pass through the walls and surround and kill the player.

Perceivable Consequence

Perceivable consequence is "A clear reaction from the game world to the action of the player". (Church Doug, 1999, Page 4). When the player dies from touching the Fygar's fire, drops a rock onto an enemy, or begins to inflate a monster, the game gives the player a specific, clear reaction. In the case of the Fygar the player will lose a life, when dropping a rock onto an enemy it will immediately flatten it. When the player begins to inflate a monster, it will cease all movement and grow larger.

Story

Story is "The narrative thread, whether design-driven or player-driven, that binds events together and drives the player forward towards completion of the game". (Church Doug, 1999, Page 5).

The design-driven narrative of Dig Dug is almost non existent. The player controls Dig Dug and must venture underground and eliminate monsters. That's the entirety of the design-driven narrative, but it isn't the entire story. The story in Dig Dug is every tunnel dug, every enemy overcome, every cunningly set up rock trap, etc. The story of the game is entirely determined by the player and their actions, thus it is player-driven.

This allows a player to create their own unique story each time they play through the game if they so choose. The smallest decision, such as tunnelling to the left as opposed to the right, can have a profound effect on the story.

Score and Lives

"One Definition  of endogenous is 'caused by factors inside the organism or system'. "Just so. A games structure creates its own meanings. The meaning grows out of the structure, it is caused by the structure, it is endogenous to the structure." (Costikyan, Greg, 2002, Page 22).

Both score and lives have endogenous meaning in Dig Dug. When the player plays Dig Dug they will attempt to get the highest score possible, this is the overall objective in Dig Dug, since the player can never "win" the game. Players start the game with a stock of three lives. Since death can happen very quickly in Dig Dug, lives are extremely precious. The player needs to have lives remaining to keep racking up the score; thus the more lives the player has in stock, the more likely they are to get a higher score.

The key point here is that although score and lives are literally a matter of life and death within the game-space of Dig Dug, they are meaningless and inconsequential in the real world. As Costikyan says "It has no concrete, real-world expression and no value in any context other than the game"(Costikyan, Greg, 2002, Page 22).

Word Count - 1319

Bibliography

Costik.com - A website run by Greg Costikyan that contains academic articles on game design and game analysis that he has written.

Author: Greg Costikyan

Article Name: I have no words & I Must Design: Toward a Critical Vocabulary for Games
Article Year: 2002

Address: http://www.costik.com/nowords2002.pdf

Checked: 2nd December

Gamasutra.com - A website that contains both gaming news and many academic pieces on designing and analysing video games.

Author: Doug Church

Article Name: Formal Abstract Design Tools
Article Year:  1999

Address: http://www.gamasutra.com/view/feature/3357/formal_abstract_design_tools.php

Checked: 2nd December

To reinforce what I said above, I'm not at all sure I'm on the right track with the review so far.

I would greatly appreciate feedback on what I've done right, and what I've done wrong and need to change.

If I've completely missed the point of the assignment then I still have time to re-write it from a different perspective.

Thanks for reading my WIP review, hopefully I'm on the right track.

Bye, bye Pre-Pass lighting

I have an announcement to make.

I am dumping pre-pass lighting.

A couple of weeks ago I started to remaking the renderer from a deferred shader to a pre-pass lighting one. Directly after implementing it, I wrote this post. At first, pre-pass lighting sounded great: faster light rendering and more variation in materials. Having seen that companies such as Crytek and Insomniac Games used it, I thought it would be the next logical step to take.

However, even as implemented it, the problems began. The first one was that specular lighting has to be made through hacks or something that makes it closer to deferred lighting. The next was that implementation become more messy. I suddenly needed to redraw all objects in two separate passes and this made the material and shader code harder to maintain. Normal deferred shading has this nice design where all material info is rendered in one pass to one buffer. But in pre-pass lighting, this spread out and makes more annoying to add new stuff and to update existing.

Still, I stuck to it, because I was sure that the speed and material variety would make up for it. One of the features I was looking forward to was making more interesting decals, with normals and such. Since only the light data is written to an accumulation buffer I thought this would allow me to easily put more effects to the decals. However, I quickly realized that I had been quite foolish and not considered that pretty much every interesting part of a materials is added when lighting it. The surface normals, specular, etc are all baked into the light data. So I ended up doing tricks that I could actually work with normal deferred shading.

So what ended up with was lighting of worse quality, compared deferred shading, and with no more room for special effects. Still, this rendering is much faster right? Well, I did some checks which I collected in this post. It turns out that pre-pass is actually slower unless in very specific situations. None of the improvements I was hoping for turned out to be true.

Still, I stuck to it. I am not sure why, but I guess I did not want to face the truth after having put so much time and effort into it. Going back to the old renderer was something I did not want to consider.

Then last week, as I was starting making undergrowth for the terrain, it suddenly happened. I realized that I had to render the vegetation twice, creating more overdraw and making it a lot more cumbersome to implement. At this point I decided that I should seriously consider going back to the old deferred renderer. What I was most worried about about was that it would exclude us from consoles, but I found out that games like Burnout Paradise used a deferred shader too, and assuring me that consoles would still be possible to do.

This post by Adrian Stone, with an in-depth discussion on the subject, sealed the deal for me and I got to work with going back to deferred shading. I had actually come across Adrian's post before when implemented pre-pass lighting, but never read it carefully. I guess it would not had made me stop then since I wanted to check it out myself, but it is interesting to see how one can convince oneself that something is correct, to the point of avoid contradictory sources. This is a very important lesson to learn and one should always be prepared to reconsider and "kill your darlings".

Right now I have fully implemented the deferred shader again and even updated it a bit too. For one thing, I fixed so the decals support all the feature I had in the pre-pass lighting shader. Since we are aiming for a little higher specs (shader model 3 or 4) for our next game, I took that into account and was able to add some other fun stuff. Examples are colored specular and saving the emission in the g-buffer (allowing to cheaply to a variety of effects).

I am really happy to back to the old renderer and now that I am adding new features things are going a lot smoother. The pre-pass renderer was not all in vain though. I cleaned up the rendering code a lot and it also made me rethink how some features could be added. Last but not least, it also reminded me that I should never get too attached to an idea.

David Bramhall & Vicky Rowley: Sony Evolution Studios

Position: Q&A (David) HR (Vicky)

David began the lecture with his journey through the industry; he started as a Q&A tester at Sony for the WRC series. After that, he worked on LEGO Indiana Jones at Travellers Tales before moving back to Sony and working on Motorstorm Apocalypse.

David then talked about the roles of different departments in the company, namely Artists, Designers, Animators, Producers and Q&A. Both David and Vicky explained the importance of these different departments and how they worked together to make a finished game.

Vicky continued the second half of the lecture by going over how to contact studios and what they expect to see on the application. CVs and covering letters were discussed, and how they should be built differently depending on who they were sent to.

Finally, they closed the lecture with an open questions session, which David used to hurl chocolate bars at us.