Friday, December 10, 2010

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.

Tuesday, December 7, 2010

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.

Thursday, December 2, 2010

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:

Wednesday, December 1, 2010

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
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
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.

Sunday, November 28, 2010

Tempest Trailer!

The following is the trailer for our gaming showing the games progression in development

The Motion controller

When designing the controller we wanted the players to feel a good sense of control over the ball, this gave us the idea of making the controller also in the shape of a ball. We believe this would give the player a grater interaction with the ball because they are using the ball in their hand to control the ball in the game, making connections between witch way u want the ball to roll and witch way you should turn your controller is easy as the player just tilts the ball in their hand in the direction they want the ball on screen to go.

Orther people such as my house mates have played using the controller and they say they enjoyed using it.

Here is a picture of how i made the controller:


Here is a game play video showing the game being played with that controller (it is very hard to play the game and hold a camera!)




Guest Speakers John Wagland from BBFC and Johnnie Ingram on Machinima

Last Wednesday I attended two different talks from two different guest speakers. Below I will recount my experience of listening to the talks, and discuss the issues they raised.

Intro on the British Board of Film Classification Talk

The first talk was from John Wagland one of the examiners from the British Board Film Classification (BBFC), and was about their purpose, methods and how they classify films and video games. The BBFC have been around a very long time, the organisation was set up in 1912 under the original name of the British Board of Film Censors.

The talk focussed mainly on film classification, but did briefly talk about games.

The BBFC is composed of 16 examiners from wide ranging backgrounds. These are split into two separate teams, one team examines films, and the other examines video games.

Film Classification

Near the end of the talk, Wagland showed us clips from various films, and asked us what age rating we would classify them as, based solely on the clip.

One such film clip was from Disney’s Rocketman film, which was aimed at all audiences (U rating). The clip we were shown was the original intro to the film, in this intro a child is pretending to be an astronaut… using a washing machine as a fake spacecraft. The washing machine starts and the child gets slightly knocked around before it opens. His parents seem to think it’s perfectly normal for him to be doing this.

The BBFC felt that this scene could be harmful to children if they copied the actions from the film. Some of the examiners felt it might have been suitable if the parents had reprimanded the child for the behaviour, since children watching would realise it was a “bad” thing to do. Part of the problem then was that the parents treat the incident so normally, barely even commenting on the child’s dangerous behaviour.
The BBFC ordered Disney to remove the footage, in order for the film to be re-assessed and later re-classified as a U rating. I wholeheartedly agree that child safety must come first, but I also think its a shame they had to cut such a humorous scene. Almost every person in the room seemed to be laughing at this particular clip, which shows that the humour did in fact appeal to all ages.

Game Classification

John Wagland also talked about games and how they are classified.

When examiners play through any game, they are given access to cheats/save states that allow them to easily and quickly experience everything the game has to offer. In this way, they do not play through the entire game from start to finish; instead they sample the mechanics of the game being examined.

Wagland admitted that games sometimes seem to receive harsher examination than film. He attributed this to parents being very concerned with the interactive nature of games. He also cited the repetitive nature of games, since this allows the player to freely repeat violent or offensive sections of the game, whereas in a film, a specific violent action will likely only be seen once in a single sitting.

Interestingly, the BBFC will lose their authority and ability to classify games on April 1st 2011. This change was prompted by the Department of Culture, Media and Sport, after they ruled in favour of solely using the PEGI (Pan European Game Information) system to rate games and other types of software.

Intro on the Machinima Talk

The second talk was from Johnnie Ingram and focussed on machinima.

The word machinima stems from, machine & cinema. machinima uses games as a tool to tell a story, in this way machinima is essentially the act of making a film within a game world.

Sometimes machinima is created directly within a game engine, with game players acting out different characters in the film in real time. An alternative is for machinima to be created using developer tools such as Half Life 2's model viewer, to view and manipulate character models. A limitation of this method in the case of the HL2 model viewer, is that anyone that has played the game will know all the original HL2 characters being used in the machinima, and so it may feel odd when they see the same character models, acting completely differently to the role they played in HL2.

Brief History of Machinima

The initial machinima videos took the form of recorded instructions within a game, such as a replay. This greatly limited the potential audience for initial machinima, since only those people who owned the game the machinima was made in, could recall the recorded instructions and thus view the film. The very first machinima movie was Diary of a Camper. http://machiniplex.net/classics.php?id=6

In the present day machinima is usually saved as an ordinary video file such as a AVI file. This allows any computer user to view the file as long as they have downloaded the latest media plug ins for their chosen video playing software.

Examples of Machinima

After explaining what machinima was, Ingram showed us two lengthy examples of it in practise.

Firstly we watched "A Warriors Dream", which according to Ingram, was filmed entirely using in-game footage from World of Warcraft (WOW). http://www.youtube.com/watch?v=j5JuypAbBH8

The films premise is that a WOW warrior character falls asleep and has a dream that they are in fact, a shape shifting shaman character. The shaman travels across the world, shape shifting each time he meets a new enemy. Eventually the dream ends, and the warrior wakes up and continues his day to day business of killing monsters.

The second example we watched was a film called Clockwork, which was created using the HL2 model viewer and HL2 assets. http://machiniplex.net/?id=22

Clockwork was made in the style of old black and white films, this really gave it a film noir vibe. The film focuses on a group of gangsters and how one particular gangster decides to attempt to redeem himself as a human being after sinking so low. To say much more would spoil the plot of this excellent piece of machinima.

Moviestorm

Machinima can also be created using specialist software such ash, Moviestorm, Iclone, Muviu, Voovees, Xtranormal and Zencub3d.

Ingram gave us a quick demo of his Moviestorm software. Firstly he loaded up a basic park-like scene, and then created a quick character to be the 'star' of the film. Next he used a microphone to record a basic sentence for his character to say in the software. When Ingram tested the sentence, he demonstrated that Moviestorm featured automatic lip syncing of recorded voice lines. Next Ingram used the Moviestorm interface to make the character give some simple gestures such as waving. Finally Ingram modified the camera settings to create two shots, the first shot shows the character from a distance, the second shot is a close up and allowed us to see the character speaking.

This brief demo showed us that basic scenes could be created very quickly and easily using Moviestorm.

Career of Johnnie Ingram

The final part of the talk focussed on Ingram's career. By his own admission, Ingram has had a very interesting career path. He began by studying Drama and English, dropped English, and then abandoned drama and decided to study films and media. Eventually he applied to a local company via email, and worked with them for a number of years, before applying to Moviestorm. He joined Moviestorm as a software tester, and ultimately he worked his way up the company to a very senior position. One of his new duties is to give talks about; machinima, his career and Moviestorm to universities and students.

Conclusion

I'm glad I attended both events. Each event offered something different, the BBFC talk taught me a lot of interesting information about movies, games and how and why they are rated.

The machinima talk was also very entertaining. Ingram's method of timekeeping was amusing; since he kept overrunning the set period of time each segment of the talk was supposed to last.

Before attending the talk I knew almost nothing about machinima. I'd watched a few episodes of Red vs. Blue a Halo machinima, and a few other random videos online, but that was my entire experience of it. I left the talk with more knowledge than when I entered it, realising that some videos I've watched in the past were actually machinima without me realising it.

This concludes my recount of both talks. Thanks for reading. :)

Films Referenced

Rocketman (Walt Disney Pictures, Caravan Pictures).

Machninema Referenced

Diary of a Camper (United Ranger Films).
Available online at: http://machiniplex.net/classics.php?id=6

A Warriors Dream (Slashdance).
Available online at: http://www.youtube.com/watch?v=j5JuypAbBH8

Clockwork (Amorphous Blob Productions).
Available online at: http://machiniplex.net/?id=22

Red Vs Blue (Rooster Teeth Productions).
Available online at: http://redvsblue.com/archive/?id=88&v=trending

Wednesday, November 24, 2010

Tech Feature: Terrain textures

I have finally finished the part of the terrain rendering that I spent most time researching and thinking about: texturing. This is a quite big problem, with many methods available, each having its own pros and cons.

I was looking for something that gave a lot of freedom for the artists, that was fast and that allowed that the same algorithm could be used in both game and editor. The last point was especially important since we had much success with our WYSIWYG-editor for Amnesia, and we did not want terrain to break this by requiring some complicated creation process.

Even once I started working on the textures, I was unsure on the exact approach to take. I had at least decided to use some form of texture splatting as the base. However there is a lot of ways to go about this, the two major directions being to either do it all in real-time or to rendering to cache textures in some manner.

Before doing any proper work on the texturing algorithm I wanted to see how the texturing looked on some test terrain. In the image below I am simply project a tiling texture along the y-axis.


Although I had checked other games, I was not sure how good this the y-axis projection would look. What I was worried of was that there would be a lot of stretching at slopes. It turned out that it was not that bad though and the worst case looks something like this:

While visible it was not as bad as I first thought it would be. Seeing this made me more confident that I could project along the y-axis for all textures, something that allowed for the cached texture approach. If I did all blending in real-time I would have been able to have a special uv-mapping for slopes, but now that y-axis projection worked, this was no longer essential. However, before I could start on testing texture caching, I need to implement the blending.

The plain-vanilla way to do is, is to have an alpha texture for each texture layer and then draw one texture layer after another. Instead of having many render passes, I wanted to do as much blending in a single draw call. By using a an RGBA texture for the alpha I could do a maximum of 4 at the same time. I first considered this, but then I saw a paper by Martin Mittring from Crytek called "Advanced virtual texture topics" where an interesting approach was suggested. By using an RGB texture up to 8 textures could be blended, by letting each corner of an rbg-cube be a texture. A problem with this approach is that each texture can only be nicely blended with 3 other corners (textures), restricting artists a bit. See below how texture layers are connected (a quick sketch by me):

Side note: Yes, it would be possible to use an RGBA texture with this technique and let the corners of a hyper cube represent all of the textures. This would allow each texture type to have 4 textures it could blend with and a maximum of 16 texture layers. However, it would make life quite hard for artists when having to think in 4D...

When implemented it looks like this (note he rgb texture in the upper right corner):


However, I got into a few problems with this approach, that I first thought where graphics card problems, but later turned out to be my fault. During this I switch to using several layers of RGBA textures instead, blending 4 textures at each pass. When I discovered that is was my own error (doh!), I had already decided on using cache textures (more on that in a jiffy), which put less focus on render speed of the blending. Also this approach seemed nicer for artists. So I decided on a pretty much plain-vanilla approach, meaning some work in vain, but perhaps I can have use for it later on instead.

Now for texture caching. This method basically works as the mega texture method using in Quake Wars and others. But instead of loading pieces of a gigantic texture at run-time, pieces of the gigantic texture is generated at run-time. To do this I have a several render textures in memory that are updated with the content depending on what is in view. Also, depending on the geometry LOD I use, I vary the texture resolution rendered to and make it cover a larger area. So texture close to the view use large textures and far away have much lower.

I first thought had to do some special fading between the levels and was a bit concerned on how to do this. However, it turned out that this was taken care of the trilinear texture filtering quite nicely (especially when generating mipmaps for each rendered texture). When implemented the algorithm proved very fast as the texture does not have to be updated very often and I got very high levels of detail in the terrain.

Side note: The algorithm is actually used in Halo Wars and is mentioned in a nice lecture that you can see here. Seeing this also made me confident that it was a viable approach.

The algorithm was not without problems though, for example the filtering between patches (different texture caches) created seams, as can be seen below:

(click to enlarge, else it will not be seen)

The way I fixed this was simply to let each texture have a border that mimicked all of the surrounding textures. While the idea was simple, it was actually non-trivial to implement. For example, I started out with a 1 pixel border, but had to have a 8 pixel border for the highest 1024x1024 textures to be able to shrink it. Anyhow, I did get it working, making it look like this:

(Again, click image to see full size!)

Next up was improving the blending. The normal blending for texture splatting can be quite boring and instead of just using a linear blend I wanted to spice it up a bit. I found a very nice technique for this on Max McGuire's blog, which you can see here. Basically each material gets an alpha that determines how fast each part of it fades. The algorithm I ended up with was a bit different from the one outlined in Max's blog and looks like this:

final_alpha = clamp( (dissolve_alpha- (1.0 - blend_alpha ) / (dissolve_alpha * (1-fade_start), 0.0, 1.0);

Where final_alpha is used to blend the color for a texture and fade_start determines at which alpha value the fade starts (this allows the texture to disappear piece by piece). blend_alpha is gotten from the blend texture, and dissolve_alpha is in the texture, telling when parts of the texture fades out.

So instead of having to have blending like this:


It can look like this:


Now next step for me was to allow just not diffuse textures, but also normal mapping and specular. This was done by simply rendering to more render targets, so each type had a separate texture. This would not have been possible to do if I had blended in real-time as I would have reached the normal limit of 16 texture limits quite fast. But now I rendered them separately, and when rendering the final real-time texture I only need to use a texture for each type (taken from the cache textures). Here is how all this combined look:

You can see small version of each cache texture at the top.

Now for a final thing. Since the texture cached are not rendered very often I can do quite a lot of heavy stuff in them. And one thing I was sure we needed was decals. What I did was simply to render a lot of quads to the textures which are blended with the existing texture. This can be used to add all sorts of extra detail to map and almost require no extra power. Here is an example:


I am pretty happy with these features for now although there are some stuff to add. One thing I need to do is some kind of real-time conversion to DXT texture for the caches. This would save quite a lot of memory (4 - 8 times less would be used by terrain) and this would also speed up rendering. Another thing I want to investigate is to add shadows, SSAO and other effects when rendering each cache texture. Added to this are also some bad visual popping when levels are changed (this only happens when zooming out a steep angle though) that I probably need to fix later on.

Now my next task will be to add generated undergrowth! So expect to see some swaying grass in the next tech feature!

Monday, November 22, 2010

How the player becomes the protagonist

Introduction
In Amnesia one of the main goals was for the player to become the protagonist. We wanted the player to think "I am" instead of "Daniel is" and in that way make it a very personal experience. The main motivation for this was of course to make the game scary, but also for the memories that were revealed to feel more personal for the player.

In this post I will go through some of the design thinking we used, problems it caused and how it eventually turned out. I will also briefly discuss the future of this sort of design.


Playing a role
First of all, it is not required that the protagonist matches the player character in order for the player to "become" him/her. As an extreme example, I see no problem with a game featuring an animal as lead character to have the player become the protagonist. The idea is not that the player should match the physical / mental protagonist, but rather that he/she should be able to roleplay him/her and to feel like really being him/her.

There is of course limits to this kind of roleplaying and certain characteristics might make it impossible for a player to feel a connection. This is the same for works in other media where the reader/viewer is meant to feel empathy toward one or more characters. Sometimes there is some mismatch that removes this feeling, and much of the work's power is lost. Note that this sort of friction is more likely to happen because of the personality of the character and not so much because the physical appearance. A simple example of this would be that protagonists in Disney movies are often very easy to relate to despite being animals.

Considering this, the general rule that we used was not to force emotions and actions that players were unlikely to accept. When the protagonist is displayed as doing or feeling something, we had to make sure that player could agree to this.


Getting into the act
In film or literature it is possible for the audience to not like the protagonist at the start, but then make them feel a connection over the course of the work. This is not possible to do in a videogame, as players must start acting out their role as soon as the game starts. If the situation does not feel comfortable at the start, then it will be very hard to connect.

Because of this, videogames need to have a tutorial of some sort where the player gets used to the idea of playing a certain character. During this phase it is also important that the player learns how to act as the protagonist, so they later act accordingly. I do not think this can be done solely on a mechanics basis, as the trial and error involved will most likely just frustrate. This is largely dependent on the space of actions available though and sometimes players will quickly realize the role they are meant to play.

In Amnesia we made the choice to be very upfront on what is expected by the player. This is accomplished by displaying messages before the game starts, telling the player what to do. The main message was a rather simple one, simply saying that the player should not try and fight any monsters. As this is pretty close to what most people would do in real-life, we basically just had to tell players that the game was not a first-person-shooter and the rest came naturally. If the game would have required more specific behavior from the player, more info might have been needed.

Once the player accepts this role and is ready to play, the next step is to provide an interface between the player and world. Here a bunch of problems arises and it becomes less clear what is the right thing to do.


What emotions to hide?
First of all, we decided to remove any form of cut-scene from the game. Upon entering a cut-scene, there is a large distinction between the kind of control a player has during normal play, creating a discrepancy that weakens the player-protagonist connection. In our previous effort, Penumbra, we had little of these, but there were still places when control was taken from the player for longer periods. In Amnesia, we only used very short "view hijacks" to display points of interest. These were not very frequent and were meant to be seen as reflexes, which seemed to be accepted for most players. Some were a bit annoyed by them though and we are not sure they were that necessary.

Next thing we decided on was that, unlike Penumbra, Daniel (the protagonist) should never comment on the situation. In Penumbra the most obvious place this happens is when a spider is spotted and the text "A spider! I do not like spiders" appear. This sort of interface where the protagonist make subjective remarks on the game world can very easily break the connection between player-and-protagonist.

We tried to skip descriptive texts completely, but this caused problems when dealing with puzzles. If players start thinking about a puzzle "incorrectly", then it is imperative that they get on the right track. In these cases, the easiest (and many times only) way to communicate this to the player is by using texts. We tried to add as many solutions to avoid having texts, but it only works so far, and eventually some kind of explanatory / hinting text was needed. If not the player would have gotten stuck instead and we thought this would be worse than having the texts. In order to keep the player-protagonist connection, we kept all of this texts very objective and impersonal, careful to not force emotions on the player.

Side note: A problem we had when removing subjective comments was the hints were much harder to write. Not being able to let the protagonist guess, use insights or personal knowledge proved quite tricky at times.

We did not remove all of the subjective protagonist emotions though. We kept the more autonomous physical actions such as panting and heart beats, a choice that proved slightly controversial. After releasing the teaser video some people argued that having these sort of reactions pulled them out of the experience. Others felt that it just heightened the experience. Once the game was released, the main complaint came at a very specific feature, namely the "sanity damage"-reaction (that happens whenever the player witnesses something frightening). In the end, we estimate that something like 15-30% of the players disliked these kind of effects.

For the people that did not dislike these effects, many felt it increased the connection to the protagonist. For example feeling as if their own heart beat faster when the protagonist's did or becoming startled when a "sanity damage"-effect told them to. This is a really interesting subject and while using these kind of effects might detract the experience for some, I think it might be worth taking the risk. So far we have mostly tried this for very simple situations, but I believe it can used to evoke much more complex emotions.


Bringing back memories
An important part of Amnesia is that players slowly learn the background of the character they are playing. As the name suggest, the game starts out with the protagonist having amnesia that sets the player and protagonist on equal footing. By progressing through the game both the player and the protagonist gain access to increasingly more lost memories, slowly getting an idea of how Daniel ended up in the situation he currently is in.

The main mechanic we used to deliver these lost memories was through diary entries scattered throughout the game. We decided to voice these in order for them to be more interesting, but I think this backfired a bit. What many players seem to have experienced was that Daniel was reading the entries aloud. Thus this proved to be a large distraction and must have weakened the player-protagonist bond for many. What we intended was for the player to hear Daniel's voice as the voice of their old self. This was probably way too obscure though and it might have been better to just had them as pure text.

Added to this was the fact that Daniel actually spoke at some points. Some lines are spoken during the start of the game and some during gameplay if sanity is too low. Again, this was intended to be lost memories, but many players did not perceive it as such and instead thought it was strange to hear Daniel talking.

As mentioned earlier, we wanted the player to feel as if the lost memories were their own. But because of the way the memory content was delivered I think the effect was not what it could have been.


Dialog
A major obstacle when trying to create strong a player-protagonist connection is that one often end up with the so called "silent protagonist". The reason for this is simply that that whenever spoken words are required, the lines spoken by the protagonist must be predetermined and chosen for the player. Either, the character simply speaks a scripted line or the player chooses from a list canned responses. Using the first type allows for more fluent conversation but removes any interaction. The second choice provides some interaction but makes conversations stiff (as other actions are only possible when in "dialog mode") and might lack options the player finds appropriate to say. Some hybrid solutions exist (like in Blade Runner where the player just sets an attitude) but the problem still remains.

Side note: Interestingly, the problem is quite opposite in Interactive Fiction. Instead of lacking options for the player, the characters one speaks to lack the intelligence to understand all possible (and fitting) sentences.

So how to solve this? Well, first of all it is worth noting that the systems mentioned above can still be used if applied carefully. If the player's emotions are in line with the protagonist's then simply having short scripted lines could work very fine. To make this work I also think it is important that the protagonist's voice is a recurring element of the game to get the player used to it. If it just pops up on rare occasions, the illusion is easily broken. Call of Cthulhu and the Thief series use this to some success (I think it is at its best when short, in-game and the player is free to do other actions at the same time).

The multiple choice system is also possible to use, but I think it comes with more problems. The biggest is that since the player gets a choice it is more obvious when the game does supply the wanted action. With other actions such as walking and fighting, it is easier to set up rules for the player on what is allowed and not. Conversations have a much wider scope and it is much harder to keep it consistent. It is also much harder to display the options in a way that feels okay. Unless they entire game is controlled with a menu-like system, having a menu pop up for a specific action is very distracting.

In Amnesia we chose to avoid conversations as much as possible and there are only two occasions when you meet another character face-to-face. And in only one of these were there any real opportunity for a conversation (with a tortured man called Agrippa). The way we went about it was for Daniel to be silent, but for Agrippa to respond as if Daniel had spoken. This gave the dialogs (or rather monologue) more flow but many players found this quite disconnecting. They found it strange that Daniel silently spoke back, especially as many was sure they had heard him speak before when reading diaries. On the other hand, it might have been even more strange if Agrippa had never asked Daniel anything and simply just spoken in direct orders or in a lecturing manner. Agrippa was put into game pretty late in development and we did not gave it as much thought as we should have, so this might have been solved better.

When creating a videogame with a strong player-protagonist connection, the best option is probably to fit the game world around a protagonist that does not require none or very simple (as in yes-no or simple vocabulary) speech. This way, the player-protagonist connections is more easily kept and consistency is maintained. An example of this is System shock where all characters are dead or talking through a one-way radio. Another example is BioShock 2 where the protagonist is a dumb robot that is not expected to speak. This of course put limits on what kind of experiences that can be made, but might be the only way to create a strong player-protagonist experience.


Problems to overcome
It is not only dialog that is a large problem when trying to make player and protagonist one and the same. Since we are trying to craft an experience where the players themselves are a central ingredient, much pressure is put on them.

A major problem is that it is hard to let the protagonist have any special knowledge. This is a reason why stories starring amnesiacs, outsiders or cannon-fodder are so common; things becomes very complicated if players need to have a deeper understanding of their surroundings. A way to solve this is to force the player into learning things before starting the game. But since reading a novel before starting the game is not really possible, the amount of information that can be given is quite limited. Another way to solve this is to have some sort of tutorial texts popping up, but this is of course very distracting.

Another issue, is that the player and protagonist might not share the same goals. For instance the protagonist might be out for revenge, but the player might not be interested in this. This makes games of this type end up with fairly simplistic motivations. It might be possible to give some kind of instructions before the game starts, but that does not seem very good to me. Better would be to provide an experience at start that sets up the player's mood to match the protagonist's. This is easier said than done though.


Why bother?
So why go into all of this trouble of making blurring the line between player and protagonist? For one thing, I think it is something that is extremely interesting to explore. So far games that try to create strong player-protagonist bonds are mostly about killings things and exploration into other themes is pretty much uncharted.

Secondly, it is something that that is unique to the medium. In no other media can the audience step into works of art themselves. And just because of this I think it demands to be experimented with. Instead of looking too much to film or other art as inspiration, we should try and do things in ways that only videogames can.


Your thoughts?
We would be very interested in hearing your thoughts on this. How did you feel like you connected with the protagonist in Amnesia? Was there any especially large obstacles for you to have a strong connection?

Also, in case you are interested in more discussions on this, check out the previous post on self-location in games:
http://frictionalgames.blogspot.com/2010/09/where-is-your-self-in-game.html

Thomas Hulvershorn: I-Play, Oberon Media

Position: Lead Game Tester
Worked on: Women’s Murder Club 4, Bubble Town

Thomas’s lecture focused on the testing side of the game development process. He explained what the tester’s job is, and how they go about testing games. As Q&A is the most common first job of students leaving university, the advice and explanations he gave were very helpful.

He also talked about Facebook games and how they functioned, particularly about how they attract customers and keep them playing. I found this very interesting, as getting customers to buy your game is pretty much the reason for the industry.

Friday, November 19, 2010

Formula 1 Sportswheel GUI Mock-ups & Adobe Illustrator Practise


I am now halfway through the development time period for my Formula 1 sportshweel re-design.

At this stage I am required to have started creating some basic mock-ups for my re-design. Below I have posted images showing each mock-up, and explained how the interface elements are positioned.

Mock-up 1 - as you can see, the track is positioned at the bottom of the screen. All other interface elements, the betting chips, the grand stand and the traffic light, are positioned above the track.

Mock-up 2 - this is the only design where the track is placed on the upper portion of the screen. I thought this would be something interesting to try in my design. I positioned the betting chips around the bottom left edge of the track.

Mock-up 3 - in this design I have positioned the track in the centre of the screen. I like this design since the various elements fill most of the screen-space which stops the game screen feeling empty. Visually I like the position of the betting chips, but the spread out nature, might make the game difficult to play.

Mock-up 4 - in this design I decided to try something different. I decided to move all of the interactive elements in my game, betting chips, traffic light play, reset and quit buttons, onto a single horizontal row. I think this will facilitate the making of bets, when players play the game.

Colour Scheme Grid - this is the colour scheme grid I created. I chose red, yellow and orange to be the predominant colours in my game. I feel that these colours complement each other well and lend the game a "warm" feeling.
 

Adobe Illustrator Practise

This Thursday Phil gave us a quick introduction to Adobe Illustrator. The interface of Illustrator is very similar to Photoshop, many of the same tools and options are in both programs.

The biggest difference between the software is Photoshop is a bitmap program, while Illustrator is vector based. Vector based images can be resized infinitely without 'pixelation' occurring and blurring the details of the image. Similarly lines don't become jagged when enlarged.

I spent the majority of Thursdays lesson having a play around with Illustrator since I had never used it before. Andre challenged me to draw a video game character, and eventually I decided to try and draw Nintendo's Kirby character, since design-wise he is fairly simplistic.

Needless to say, drawing Kirby proved to be much more challenging that I'd have imagined. I didn't realise how much effort went into even a simple character design such as Kirby before trying to draw him.

Eventually, with a little bit of help from both Andre and David, I was able to create the below image. Mainly I used the pen tool, combined with ellipses to form Kirby's body, feet and hands. I used the convert anchor point tool to move the various sections of the ellipse to create the shapes I wanted.

Kirby - This is my attempt at Kirby. I'm pretty proud of it. I might edit it sometime to add light and shadow to the image, this should make Kirby look much more 3D.
 
Kirby Reference Image - I based my attempt on this picture of Kirby.

It's not perfect but I think it's pretty good considering I'd never used Illustrator until earlier that day.

Overall it was a very enjoyable lesson. I learnt about the program while doing something that interested me, creating a video game character using various tools in the program. Thanks for reading. :)

Natural Funativity

This week we were asked to read an article titled ' Natural Funativity', an interesting title to be sure. (The title is a pun on natural selection). In this blog post I will summarise and discuss what I think are the important points of this article.

Intro

Fun in itself is not a useful term when critically analysing a game, the term 'fun' is too subjective and not specific enough. This article written by Noah Falstein attempts to remedy this by looking back at the past of our human existence to determine why we like to partake in certain activities and find them 'fun'.

In the article fun is broken down into 4 distinct types these are; physical fun, social fun, mental fun and blended fun. Below I will describe what each type of fun involves and where it likely evolved from. The article also mentions something the author calls, refined sugar syndrome, below I will explain what this means, and how it relates to the different types of fun.

RSS - stands for Refined Sugar Syndrome. It is the act of wanting more of something, even though we know it is bad for us. It is the act of refining something to make it more extreme, e.g. a person’s love of fast cars may date back to when we needed to move faster and faster to escape hungry predators. The modern car can be seen as a more refined version of that original love of speed, which helped us to survive. It's the same principle, but taken to a much greater extreme.

Physical Fun - is very likely to be linked back to the pure survival skills, such as hunting and gathering that our ancestors possessed. Hunting skills can be seen in a large variety of games, including but not limited to; racing games (chasing down the 'prey', or escaping from the 'prey'), FPS games, where the player physically runs after the enemy player in an effort to destroy them, or conversely, when low on health, attempts to escape from the enemy player. Physical fun is not just limited to tool use. The mere act of interacting with the game itself; whether it's by using a game controller, mouse and keyboard combination, or one of the various new motion sensing technologies, (Wii, Kinnect and Playstation Move), this interaction and manipulation of the input peripheral is in itself an act of physical fun.

Gathering skills can also be seen in many different types of games. This type of skill likely dates back to our time as berry and cherry pickers, once again an essential part of our survival. Here are some examples of collectibles from a variety of different video games; Pacman - dots, Mario - coins, stars, Zelda – heart-pieces, weapons, tools, Final Fantasy - different weapons, potions, etc. Collecting is also a large part of MMORPG's (massively multiplayer online role playing games). In most MMORPG's the player must acquire better items in the form of progressively better 'loot' as they continue to fight monsters which get increasingly more difficult. The new loot keeps the player powerful throughout their time playing the game. The Pokemon video games were entirely based around the idea of fighting and catching hundreds of different monsters, as the games catch phrase, "Gotta catch em' all!" states. As you can see, the act of collecting is crucial to many video games.

Social Fun - can be traced back to our need to survive as a species, via reproduction and living as part of a larger tribe or clan. Just as important is our development as a species with our love of storytelling. The earliest form of story was a way of imparting information and lessons to future generations. Stories can impart knowledge even if the author of the story has long since passed away. Stories then, are one way we record events throughout the ages.

In games social fun can take many forms, here are a few of the most common ones; in most MMO's; especially those that discourage or disable player vs player killing, the impulse to help out other players especially if they are new to the game, exists. Players often travel around the world in clans, to complement each other's individual skills, and stand a better chance against the majority of monsters and quests throughout the game. This type of play is very reminiscent to how we as human beings behaved back thousands of years ago when we lived as part of a larger tribe, in order to stand a better chance of surviving.

Mental Fun - can be traced back as an alternative to always hunting. Instead of instantly going outside again after returning from a successful hunt, one of our ancestors could have taken a break from hunting, and played a simple game using a piece of wood and stones. The single piece of wood would be balanced on a stone, and the ancestor would throw other stones at the wood to try and overbalance it. In this fashion the ancestor is improving his mental abilities, whilst in a safe environment. This also has the added benefit of helping his muscle tone, since he is getting a miniature workout by throwing the stones, even when not actively hunting for food.

Intelligence itself is sometimes defined as the ability to find and manipulate patterns. Imagine if you will the importance of our ancestors recognising the difference between a normal field of grass and a field of grass occupied by a Sabre-tooth tiger, lying in wait. It's not difficult then to see how mental fun would have been essential to our ancestor’s survival.

In games mental fun can take many forms, puzzle games such as Bejeweled, are perhaps the most obvious example in video games.. Jigsaw puzzles and the ever popular Rubix Cube are two common examples of non-digital mental fun. I imagine most people will at some point in their lives, have completed a jigsaw puzzle or grappled against a Rubix Cube.

Blended Fun - Most modern entertainment is made up of a mixture of the above categories.

A common sport such as football for example, uses elements of; physical fun - kicking, throwing and catching the ball, social fun - team work, communication throughout the game, and mental fun - the actual overall game-plan and tactics throughout each minute of the game, e.g. when to put more of an emphasis on attacking, when to shift that emphasis largely to defence etc.

Rayman Gold

Video games also use a blend of the different types of fun listed above. Consider the 2D platforming game Rayman Gold. Rayman contains a large element of collecting. In Rayman the player must collect all 100 'tings' (balls of light), in order for the exit to the next level to appear. To accomplish this, the player must practise playing the game, learning the controls as they go, along with learning how to execute certain moves effectively. This is another aspect of physical fun.

Rayman Gold also contains mental fun. As the player plays through the game they will encounter a variety of different enemies, based on each environment in the game world. Many of these enemies use specific attack patterns which need to be memorised, in order to effectively defeat them. This mechanic is most prevalent in the many Boss stages throughout the game. The player must fight each boss several times before they will be able to effectively recognise and exploit the weaknesses in the attack patterns that each boss utilises. Only then will the player be able to triumph and move onto the next environment of the game.


Rayman Gold: Mr Skops Boss Battle

Rayman Mapper

It could also be argued that Rayman Gold contains social fun through the use of the built in Mapper. The Mapper program allows the user to create complex, 2D single player levels, much like those that were included in the game. The player is, in fact, given the exact same tools that the Developer (Ubisoft) used to make the levels in the game, and so can create levels nearing or even surpassing the quality of the Ubisoft levels.

The learning curve of the level editor is almost non existent, I should know since I was able to make fairly complex levels back when I was only around age 7-8. The level editor is comprised of two main screens; the first screen is the 'level' being constructed itself; this will start of as a completely blank background.

The second screen is a 2D template image containing all the individual elements of one of the 'themes' from the game. The themes are, Dream Forest, Band Land, Candy Chateau, Picture City, Blue Mountains and The Caves of Skops.. To start creating a level, the play simply needs to drag a box around an element from their chosen template that they want in their level and then use the ‘Ctrl C’ and ‘Ctrl V’ hotkeys to copy and paste the element onto the other screen. (Fun fact: The Rayman Gold level editor taught me those two extremely common hotkeys. Before playing the game, I didn't know of them).


Rayman Mapper Dream Forest Template

Anyway, back to how it could be classified as social fun. After a level has been created, it can be uploaded to the internet to allow other Rayman Gold players to experience it. Sometimes the players may give the level author feedback, thus communicating with them. This is a simple form of social fun. The author can use this feedback to improve their level, and then re-upload it to get more feedback. This iterative process of improving the level may overtime produce something of great quality that many people will enjoy playing.

Conclusion

In conclusion I thoroughly enjoyed reading this article. The possibility that fun can be linked back to our evolution as a species, and can then be broken down into four sub-categories is an intriguing one.

Bibliography

Falstein Noah, "Natural Funativity", 2004.

Games Referenced

Rayman Gold (PC, Playstation) Ubisoft

Wednesday, November 17, 2010

The Controls




This layout will be typical of a FPS game style game play with the RPG controls incorporated.
The reasons behide choosing such a layout is because the WASD style layout is used through PC gaming and making radical changes will confuse gamer already used to this style. And also it works plain and simiple, it feel more natural then using the arrow key(for example) to move.
The Xbox360 controller layout is also a FPS style layout, I choose to very a layout similar to whats in COD:MW for a couple of reasons. The first is that again this style layout works very well, the buttons you use most are the most accessible. Also the COD Franchise is one of the best selling game out there, millions of people play it on xbox360. Therefore millions of people are already used to this layout, making it easy for people to pick up the controller and start playing straight away. There are also the Buttons used for the power/skills, that blend easily into the FPS sytle controls.

Monday, November 15, 2010

The Review

My Game Enviroment I believe worked out very well. The enviroment was meant to be a desert Oasis in the blitz of a sand storm. I came up with the game idea from watch and playing alot of SciFi theme entertainment. The desert oasis came about from watching a movie called "The Objective", in which these specials are hiking through a desert on a mission and find a desert oasis. From all this I wrote the story, thumbnailing ideas and concepts as i went. The SandStorm is was something i created to show a hostil desert enviroment.

From the thumbnail stage i started on the blueprint and asset list. Creating these helped me flesh out the level into the bricks i needed to bring it to life. The Genre and target audience was important to get sorted early on, as these would influince the game in many ways. I also added the Objectives(primary and secondary) into the blueprint.

Controls, Interface, and Gameplay mechanics was also an important stage to get down early. The way in which the game is played can have huge effects of the models and textures of the end work. The modelling then began, I started with the High Priority assets as the game had no hope of working without them, finialy finishing with the Low Priority assets. The UVW unwrapping was a long process but I completed them with only minor problems that are now sorted. Texturing was good fun, seeing all the hours apon hours of work coming togather was a great feeling.

Putting everything into Unity was the next step. I made the terrian and textured it next, adding sand dunes and mountains. I placed all the Assets in there spots according to my blueprint. The SandStorm created with the partial effects looks great ingame and dont chew too much resources. Infact the game itself doesnt chew too much for a large level, which was part too optimizing the enviroment to work on computers with lesser specs.

It came from an Idea and now its a full Unity Game Level Enviroment, the Desert Oasis being hammered by a SandStorm.