My Blog

[someblogontheweb]

Create an Item! Mass Effect 3

            It is hard to think of items to add to your favorite games because when you remember them you tend to only remember the good parts and not what areas needed improvement or even where there were massive holes in the game. This is a problem that really prevented me from coming up with items that fit into games that I haven’t played extremely recently. However, when recalling my experience with Mass Effect 3, I think I’ve come up with a suitable to the game.

            That addition would be a detonate-able explosive. Since a lot of the single player and co-op missions take place in a contained arena like environment where you hold off waves of enemies until your objective is complete, it makes plenty of sense in my mind. The explosives could either be remote trigger or proximity trigger (the pros and cons of each I will get to momentarily). These explosives would be picked up much like ammo and grenades, from various drop points within the level. Given that they would fall under the heavy weapons classification, the soldier class would be able to hold more of these traps that the other classes to balance for it not having access to tech or biotic powers.

            If the player chooses to use the remote trigger explosives, it would give them a lot more control over chokepoints with particularly difficult pieces of cover. By planting the explosive before the enemies showed up, you could retreat, wait for them to position themselves and then blow them all up from complete safety. Another tactic would be to place them near the explosive containers placed in the level, effectively increasing their power or adding special effects to the blast. A final tactic would be to place them in the path of a particularly tough but slow moving enemy and then detonate them when the enemy reaches them. The downside to these explosives would be that they may overcomplicate combat and could overload the players with too many things to worry about at a given point in combat. The player may miss other very important information or signals if they are too busy worrying about detonating their traps. This version of the trap is more complex but yields rewards for those who can use them properly.

            If the player chooses to use the proximity trigger explosives, it would give them a lot less to worry about, just place them in strategic positions and forget about them. It’s a simpler version of the trap that allows players with too much to do in combat already to still enjoy them. These traps would be especially effective at guarding paths to the player’s flank where the would not see enemies coming. Their downside would be the lack of versatility and they won’t always detonate on the enemy you want.

            In order to prevent these from breaking gameplay, you would have to place fairly tight restrictions on how many the player can have. Laying down a huge minefield to have a boss die almost immediately upon entering the area seems a little too close to a dominant strategy. This also opens up an opportunity for a new type of enemy that has the ability to disable the traps if they spot one. When they start disabling the trap it would alert the player and they would then have a small window of time to kill the enemy before their trap is removed. The trap would not be able to detonate while it is being disabled.

            These traps would have me the holdout sequences in Mass Effect 3 feel much more tactical than just hiding behind cover and mowing down waves of enemies.

[someblogontheweb]

Destruction Masking in the Frostbite 2 Engine

            I thought I would go a little off topic from what we have been learning in the lectures to talk about one of my favorite features in a modern game. That feature is destructible environments. I feel like they add so much to the game world that I did some digging to find out how it is done. This blog will focus on the visuals of the destruction as opposed to the actual destruction itself (I couldn’t do that justice in 4 blogs, let alone 1). As reference I used the slides from the following link.

http://dice.se/publications/destruction-masking-in-frostbite-2-using-volume-distance-fields/

            Slides 2 through 5 show the basic process that the Frostbite 2 engine goes through when handling the destruction effects. It removes a section of geometry from a model, adds a high detail destruction mesh around the edge of the hole, and then alters the texture on the building in order to make it look like the mesh fits.

            The first step to making the destruction mask is to generate invisible spheres on and around the point of impact. This determines the area that the explosion had an effect on. Using the spheres, the engine computes a very low detail distance field which is stored as a volume texture. It is important to only use one texture for each piece of masked geometry in order to prevent issues that are caused by overlap. The next step is to turn the low quality texture into a higher quality one in order to more accurately determine where the final texture will be displayed. After this the generated area is scaled up to encompass the area where the final texture will be applied. During this stage the detail of the texture is also applied to the mask. Finally the actual texture is applied, creating a nice blend from building to destruction to the hole that was just created.  (Also as noted from the slides, certain parts of this process are done in two lines of code.)

            One of the issues of streamlining this process was that the smaller textures that would not make use of all of the set dimensions of textures on certain platforms. This was a huge waste of memory. In order to fix this, the developers implemented a texture atlas. A texture atlas is a larger image that is made up of a bunch of smaller images. This prevented the waste of a lot of memory by combining smaller textures into a larger image from which you the just take sections of in order to display the correct texture. This also simplified the package of the textures into the game, but also raised its own issues. To prevent parts of certain textures either leaking out of the atlas or on to other textures that are in the atlas, the developers need to add “padding” to the atlas. Padding is essentially just space in between parts of the textures, so that they don’t overlap or enter a different texture sample.

            In order to actually draw the destruction mask efficiently, the mask is rendered as a deferred decal as opposed to making a branch in the pixel shader. Branches slow down the process and thus should be avoided. In order to create a deferred decal you must first draw the scene’s geometry. Once drawn, create a convex volume around the area in which you want the decal to be placed. Taking data from the depth buffer, you convert the decal to the local position within the volume. You then determine its opacity (from the texture) based on its position. Finally you blend the decal on top of the geometry making a very clean looking effect.

            Another problem that needed solving with this method was the normal maps. In order to get a proper effect it was necessary to use tangent space vectors. The regular G-buffer normals don’t produce the correct result, so instead they chose to send an index to the g-buffer with the main geometry. That index is used to sample a texture which contained a lookup table for the tangent vectors needed to display the correct effect. This works because there isn’t a need for a lot of tangent vectors.

            Anyways I hope you enjoyed this (very) brief look into some of the visual work that the developers over at DICE are doing in the Frostbite 2 engine. 

[someblogontheweb]

Create a game item! : Alice Madness Returns

            Alice: Madness Returns was one of the games I enjoyed the most from recent memory. The 3D platforming was very enjoyable (if a little buggy) and the combat felt very smooth. There is a very limited amount of game mechanics, even though they were very well refined. I still feel like there was room for improvement in certain areas, specifically in the area of collectables.

            After playing a fair bit I thought that there would be a good solution to some of the blind corners and super high ledges. Add a form of a grappling hook mechanic to the game. This seems like a strange sort of mechanic to add to a platformer where the character already has 3 jumps. However there could be some definite benefits to adding one.

            Firstly it would add some interesting collecting mechanics. For example, there are picnic baskets in the game. Using the grappling hook, you could grab onto the handle and pull it to you. The end of some of the extra jumping puzzles resulted in getting these picnic baskets which are full of lower value collectables. Hiding them sneakily in the distance and on hidden ledges close to the main path would be just about as challenge as some of the minor jumping puzzles. This would encourage more looking through the detailed environments as opposed to just looking for the cues for a hidden platforming section.

            In combat the grappling hook could be used as a way to disarm the opponent or knock them off balance. This would be very helpful to the player as some of the enemies nearly constantly block and this would give an additional option as to how to handle that situation. Since the combat system is not perfect a little flexibility in terms of tactics would be a welcome addition. By the same mechanic, if the enemy is small enough you could pull them off balance or off their feet entirely. The latter of the options could be used to also knock down other small enemies, allowing you to switch weapons and quickly finish them off. For use on flying enemies, it could either pull them into melee range or just pull them to the ground, allowing you to maneuver over to them and attack. As I said previously adding a little flexibility to the combat would be nice, because it does get a little repetitive.

            Finally, it could definitely be used to assist in the platforming sections of the game. Since the game has a lock on system in it, the levels could include occasional hooks (or other targetable device) meant for the grappling hook to latch on to. The player character would then swing on the rope allowing them to reach a new area. I thought of this specifically because of the occasional blind corner that you have to jump around. Since you can’t see where you have to land there is a decent amount of guesswork involved and sometimes the camera doesn’t adjust quickly enough for you to be able to make it to your destination. Falling because of this can be a little frustrating and that frustration is preventable.

            Anyways that’s my logic behind why I think Alice: Madness Returns could use a grappling hook. Although I suppose it doesn’t really fit in terms of the world the game is set in since I don’t know how you could dress it up so it wouldn’t stand out. Nevertheless it would add some interesting changes to the gameplay.

[someblogontheweb]

Emotional Contagion 2: Farcry 3

            It took me a while to think of what game I wanted to do the second emotional contagion blog on. Looking back, I’ve played a lot of games, but not a lot of them got me really emotionally involved in the game and its characters. I remembered my time playing Farcry 3 somewhere along that train of thought and then I knew that it would be the game to write this blog on, so without further ado, let’s get into it.

            For most of the blog I will be talking about the story events in the game, and more specifically the character Vaas. So I will give the big old spoiler warning in advance.

This is a link to most of the cut scenes involving Vaas in the game. I feel it is important to include these for you to truly get a feel for his character.

(Warning: very NSFW because of a lot of swearing, vulgarity and a little nudity.)

(Also plots spoilers)

http://www.youtube.com/watch?v=7ai3Maj9IZQ

            All of Farcry 3 follows Jason Brody and his tale after he and his friends are captured while on vacation. The larger issue at hand turns away from Jason’s quest to save his friends and turns more towards his quest for revenge and steady descent into madness.

            Back to Vaas, in my opinion he is one the most well written characters in modern video games. He has completely lost himself in a world of insanity and chose to embrace it. He is the embodiment of the island and all of its madness. He seems almost to take a shine to Jason at some points, even though he is trying to kill him. However it seems at times that his madness has set him free.

            Jason’s story parallels Vaas’s, or so we are led to assume. Jason starts killing because of his family, but it is never enough. As the game progresses he even notes becoming indifferent to all the killing he has to do. Later on he starts to have doubts as to if he even wants to go back to his old life after all that has happened.

            As I was playing, I noticed the feeling starting to creep into the way I felt about playing. Early on I would stake out my targets, watch for the patterns, and then go in silently and try to do everything as quickly and quietly as possible. However later in the game, the hunting and killing becomes easier. Partly due to the amount of upgrades and fancy weapons you’ve and experience playing the game, but a part of me feels like this was also designed to show Jason’s change as a character. Sometimes I wouldn’t think twice about charging headlong into a group of enemies with nothing but a machete and coming out the victor. By no means was that the easiest or most effective way of handing the situation, but it was fun, and that was all that mattered.

At points I’d forget about the quest to save my friends and escape the island (especially after Vaas’s death). When it came down to it, Jason’s friends were not very interesting. I’m sure they played this up to make it feel like returning to civilization would be a return to a very boring way of life, where you were just doing the same thing over and over and over again. That is what Vaas defines as true insanity, a view that I’m inclined to believe now after playing the game.

After a number of encounters, the final battle between Jason and Vaas takes place. Rather than being his chance at freedom from the island, killing Vaas frees Jason from his old self. It is one of his final steps to embracing the madness that has led him here. By this points Jason really doesn’t know if he wants to leave with his friends. He feels that he is doing important work on the island and that staying would be a more enjoyable experience than leaving.

As a quick note the game kind of goes downhill after killing Vaas. The antagonist that steps in to take his place is not nearly as interesting a character. This could be because the developers wanted to really drive home that the people in the world outside the island were not nearly as deep and interesting (or utterly messed up).

The game didn’t even let you escape from the madness during some of the loading screens. Quotes from Alice’s Adventures in Wonderland and Through the Looking Glass were displayed, and they helped to illustrate Jason’s descent into madness.

Playing this game dragged me along the journey with Jason. I enjoyed the descent into madness. The whole atmosphere of the island, the characters and everything was fantastic. I played that game through the night and into the next dawn without even realizing it. I felt the same draw that Jason did to stay on the island because even though everything was insane and nonsensical, it actually made more sense than the alternative. That game snuck a little insanity into my life and made me want to embrace it. The same insanity seeped out into the real world and changed my perspectives on certain things.

Farcry 3 is one of my favorite games of all times and I would go as far as to say that the game is a masterpiece. If you haven’t played it, play it. Experience it. Descend into the madness of the island and enjoy every minute of it like I did. 

[someblogontheweb]

PVP Fight 2

I did this blog on the level HueHueHue Updated 3 made by Jordan Thompson.  

The level was segmented into 4 different puzzles, so I’m going to talk about each one in the order they came up.

            The first area you enter into is a narrow hallway with a pit in the middle and a cube dropper off the right side of the picture. When playing through, it took me a minute or two to figure out what you had to do in order to progress, since it is not really apparent from where you stand above the pit. The difficulty of this puzzle came more from figuring out where the spawned cube had to end up rather than actually getting there. In my opinion this seems a little backwards, a puzzle’s endpoint should be fairly apparent, whereas the method to reach the end of the puzzle should be what is difficult to figure out. After a couple of minutes (and one unfortunate swim in the water) I was able to find the button that was home to the cube and moved my way to the next section of the level.

            In this room, it is immediately apparent that you need to retrieve the sphere and place it in the sphere button (which I’m standing on in the picture). I found this puzzle to be much easier than the first. It definitely helped that the end goal of the puzzle was apparent from the start, but it also called for less skill that the previous puzzle. This room also felt very large of what the puzzle was. To get the sphere, you just need to use the light bridge to get to a button that turns the fizzlers off momentarily. In the brief timeframe it is deactivated, you use a portal to get the sphere. A very large portion of the room is never even used and feels like wasted space. The empty space isn’t even visually rewarding because it looks like the rest of the level (though that is more the fault of the minimal available default assets you can use when making the level).  After placing the sphere on its button, its back out into the narrow hallway to ride a newly activated funnel to puzzle 3.

            This was my favorite part of the level. A small platforming section amidst the usual puzzle solving that makes up a Portal 2 level. It was a sweet change of pace. The time limit added by the raised platforms (not depicted) really added a sense of urgency to crossing the room. While I supposed this (arguably) doesn’t represent a puzzle in its fullest sense, it definitely was a challenge.

            The final puzzle involved clearing a room of turrets using a laser.

(The turrets were originally in the alcoves pictured)

            Clearing out the room was fairly easy. However, once I was inside the room I started looking around for where the cube was to place on the button. After a minute I realized that I needed to use the reflector cube. Clever. One short aerial faith plate ride later and the level was over. I feel it worth noting that although the room with the final puzzle in it was large, it didn’t feel as empty as the other room I mentioned because there were more things going on. This sort of relates to the principles of making an area feel alive that we covered in class.

            On the whole, each puzzle/challenge was well designed and enjoyable. Other than the comment I made about that one room feeling too empty there is only one other thing about the level I would change. It feels like the puzzles were out of order. Since the level was highly modular, and for the most part each puzzle happened and affected only a small part of the level, I feel like placing them in a different order may have been more effective. For example, the hardest (in my opinion) puzzle was the first one presented to the player. I thought that this kind of built the difficulty up prematurely and it didn’t really get harder. This difficulty imbalance was sort of noticeable and left a little to be desired in the later puzzles.

Anyways those are just my thoughts on the level. Good work Jordan, I had fun playing the level.

[someblogontheweb]

Domain Specific Languages.

This blog will be focusing on the presentation we watched in class to do with Domain Specific Language (DSL). So let’s get right into it.

What is a DSL?

A DSL is a programming language that is meant to be really good at handling a certain type of problem. They are meant to be easy to understand and use so that you do not need a dedicated programmer on every part of the development team to handle turning the various parts into code that is usable in the game.

Why would you want to use a DSL?

Well there are several good reasons. Firstly DSLs are closer to the way that designers and artists think about what they are working on. This helps keep code looking cleaner, and by making a DSL your cut scenes/AI/ect are not hardcoded into the engine and are instead stored in a format that is closer to scripting that engine code. Secondly, using DSLs severely reduces or eliminates issues that come from working with the low level code, making it much more designer/artist friendly. These issues cause concerns that designers don’t really to worry about, and using a DSL allowing the dedicated programmers to worry about those problems where the DSL is interpreted as opposed to having a less qualified team member do it. Thirdly, since a DSL is a fairly focused language, it removes concerns about other things not pertinent to what you are trying to do. Since DSLs have the traits I just mentioned, they are used for make the AI in games. AI generally involves solving a narrow set of problems using techniques that are well used.

Using DSLs for AI helps greatly when debugging the logic behind the AI. Since the DSL is expressed at a higher level, it is much easier to understand at a glance and figure out where the problems are.

What advantages does using a higher level language, like a DSL, have?

Well for one thing you don’t have to manually handle the memory allocations in the language. You can leave that to the programmers who are (probably) much better at dealing with that sort of thing. The syntax for the language is also a lot simpler to understand. This helps with the debugging of the code and also with its programming since it is much easier to learn. That also opens it up to be used by designers and artists, who typically do not have as good of a knowledge of programming languages. This removes the need for a dedicated programmer who knows the engine code to be constantly helping every part of the development team. Since the language is a higher level, it is less likely to cause game breaking bugs in the core engine code, which saves a lot of time in case someone who doesn’t know what they are doing goes in and mucks around with your code.

Isn’t making your own programming language difficult?

If you stick to traditional ideas about making languages then yes, it is. However, since a DSL is meant to be simple and focus, it eliminates a lot of issues that full programming languages have because it doesn’t even have to deal with them. They also don’t need as much up front work as a generic language would need. They also don’t require compilers, complex parsers or virtual machines (VM).

Having a simplistic syntax removes the need for complex parsers, and thus can also use existing file formats and not have to create one specific to the work that we’re doing. The use of the code doesn’t have to be very complicated either, so its parsing can be done at runtime.

What are some guidelines for making a DSL?

You want your DSL to take configuration and logic code of the core engine and move it into the DSL to make. That’s what the basic goal of a DSL is. The aim is for that goal to be as simplistic as possible while still working. You need to know what your DSL has to solve, and focus its creation around handling those problems. In terms of AI, it needs to be able to pathfind, anticipate situations, responds to events, and determine its behaviour. The best way to work out how to create the DSL is to determine the decision making logic, figure out where the logic tree branches, and make use of the DSL there.

It is very important to be careful of how detailed your DSL is. If it becomes too detailed, it becomes more of a general language. If it isn’t detailed enough, then it is not nearly as useful as it should be. The syntax should be easy to read, understand and it needs to be clean. Don’t be afraid to use existing file formats for simplicity. The code should very easy to parse and doesn’t use and kind of complex grammar. The closer it looks like to a readable language the better.

A final word of warning would to be not to turn everything into a DSL. If low level logic is needed, put it in low level code. It can take a lot of effort (that may ultimately be wasted) if you try for put low level logic into a high level language.

[someblogontheweb]

Reward Systems

It’s been a while since the last lecture summary, so hopefully I’m not too rusty at these.

            Reward systems are an incredibly important part of gameplay. Without them things in the game world just happen with no effect on the player, which makes them feel detached from the experience because what they are doing is having no effect on the world they are playing in. it also doesn’t motivate the player to continue playing.

            According to Wang & Sun, there are 4 types of reward systems and 8 forms that those rewards can come in. Firstly, the reward types. These are Glory, sustenance, access and facility rewards. A glory reward system is one that the player can use to compare themselves to others that play the game. For example, getting a score that is higher than a friend’s or getting a powerful item that you can brag to other players about having. A sustenance reward is a smaller reward that works towards a larger reward. For example, collecting a resource that is useable later would be a sustenance reward because you get a little reward for having the resource, and after collecting a lot of them you can turn it into something. The something that you get out of it serves as a larger reward for your effort collecting the little rewards. Access rewards are those that give the player new information or story. This generally comes in the form of a cut scene. The final type of reward is a facility reward. Facility rewards are those that affect gameplay along with being a reward. For example, leveling up or getting a powerful weapon is a reward in itself, but it also allows the player to do things in a new way.

            The reward forms were also mostly listed while explaining the types, but I will do so again quickly with a little expanding on each.

Score Systems: a reward of points or another collectable that can be used to compare how well you are doing at a game to how other people are doing.

Experience leveling system: the reward here is that the player character becomes more powerful and/or learns new abilities to make the game easier.

Items: a reward of an item is a good way to make the player character stronger, and also a way of comparing yourself to other players.

Resources: a small reward that is collected many times, building up to a larger reward when enough of the resources are collected.

Achievements: a reward used for marking progress in a game and/or comparing your play to others

Feedback: a good reward to make the user feel like what they are doing matters and make them more involved in what is happening in the world.

Plot animations: a visual reward for players when they complete a certain task, making a visually appealing sequence of events and possibly plot advancement.

Unlocking Mechanisms: a reward that grants the player access to something new, whether it be a new area or ability.

The social value of a reward is a big draw for a lot of people, and it is part of what makes Facebook games so popular. They are free, so all your friends can play and you can all compare progress or how your farm is doing. Rewards also have an effect on gameplay. These make the player want to keep playing to discover what effect their new item has on gameplay. A reward’s suitability determines how well the reward fits the situation. Lastly rewards should also be proportional to the time and effort put in to get that reward.

It is important to determine what a good reward schedule is for the player. If you get a reward every time you do something (ex. kill an enemy), it becomes less of a reward and more of an expected outcome. The rewards should be parceled out in a manner that keeps the players enticed to continue while not being constant. I’ve used this before when preparing various D&D encounters for my friends to play. Some days there aren’t any items to be found after a fight, just a progression in the story, other times its just some money and potions, and very rarely I put in a rare magic weapon to make sure they know that their efforts are worthwhile. These rewards keep them motivated to press on and keep playing even if they aren’t interested in the particular story arc that’s happening at the given time. 

[someblogontheweb]

Navigation in the Insomniac Engine

            A huge part of modern AI is how the various NPC’s navigate the levels. To make a believable AI experience in AAA titles, they need to be able to navigate the level dynamically as opposed to the same scripted movements over and over again. This also generates more interesting gameplay and adds replay ability to the game.

            There are a few basic things that the AI does in the Insomniac engine to determine what course of action it should take. It scans for targets, determines their threat level, and then makes decisions accordingly. A basic decision would be whether to shoot at the target or to move (either to cover or to a better position to shoot at the target). It is also important to the AI to determine where to spawn the NPCs. The player should not be able to see them spawn and they should be able to easily start navigating through the level.

            At the moment the most common way for AI to determine a path to their destination is using the A* search algorithm, which determines the shortest route to a destination point while navigating around obstacles. While it definitely is not as efficient as it could be, it gets the job done. There is a lot of research being put into the field of path finding at the moment and will hopefully yield some very useful results.

            The basic flow of the AI in the Insomniac engine is roughly as follows:

Determine the AI’s navigation requirements. This generally consists or a “Go-To” command.

Determine the path to the destination and smooth it so the NPC doesn’t clip through parts of the environment.

Navigate around any obstacles in the path between the NPC and the destination.

Take the generated information and turn it into inputs for the animation system to handle the animation of the NPC.

After the previous steps you end up with the position and orientation of the NPC.

The engine started out using way-volumes for navigation. This was far from ideal because designers had to create every volume and link them to other volumes. That is incredibly time consuming and the effort could be better spent elsewhere. Each of these way-volumes was used as a node in the A* search, which then allowed the AI to traverse the level.

            These were fairly humble beginnings compared to what the engine can now do. After a few games to refine their work on, the Insomniac engine has become quite impressive in terms of its navigation ability for its AI.

            Basic navigation through the levels is now done using a nav mesh. Nav meshes are essentially invisible polygons laid on top of the world. These polys are used as nodes for the A* search algorithm. In earlier versions of the engine, these meshes were created in Maya and had up to 8 sided polys in them. After refinement they discovered that triangulating the nav mesh, making all the polys 3 sided, was the most efficient way to handle the processing of it. The nav mesh is also now generated by breaking the world down into voxels and then building a voxelized nav mesh from the chunks, after smoothing out some of the rough parts. Process also detects the outer edges of the nav mesh and leaves a bit of a buffer space between it and the edge of the world. At the end of the process the nav mesh is triangulated to make it more efficient.

            Depending on parts of the level geometry, the nav mesh wouldn’t generate properly, so they created a tool that allows the designers to go into the nav mesh and fix the parts of it that weren’t created as they wanted. It allowed them to create custom override polys so that the AI would avoid certain parts of the terrain that were causing issues or to patch holes that were created in the mesh.

They also had issues with special types of navigation between different parts of the nav mesh, like using teleporters, ladders, or jumping/climbing. Since the traditional way of doing these things using point to point links weren’t very designer friendly. Instead, they created something called custom clue boxes which were much more tolerant of changes in level design. A custom clue is an edge of detection that fits within the nav mesh. Using custom links which define the type of travel in between, clues are paired together, allowing for much easier AI movement around the level. Their ease of use allows for many clues to be created in a level, allowing for the AI to seek out and use multiple different paths on the way to its destination. Certain parts of the navigation calculations are now being offloaded to the GPU as shaders to help speed up processing time.

In order to create proper obstacle avoidance, the developers wrote the AI to generate escape tangents around either side of any oncoming obstacles. These tangents were then checked for collisions with other objects, and the best path was chosen. While this was an effective enough solution, the AI would still sometimes get caught in small spaces between objects and the edge of the nav mesh. Their solution? Rotate that escape tangent by ~90 degrees so that it would appear the least desirable of the escape tangents.

Another very important point of AI navigation in the Insomniac engine is how they handled moving around corners at high speeds. Generally running around corners caused the NPCs to clip through the walls. This was solved by creating a Bezier curve on the path and aim for the centre point of the curve in order to keep a good momentum going around the corner and not clip through the walls.

[someblogontheweb]

Cameras in Game Engines

            Cameras are one of the most important elements of modern day games. Without a camera system chances are the player will not be able to see what is going on in the game (it depends on the game, but most use graphics of some kind that need to be displayed to the player). A bad camera system can really hurt a user’s experience with the game. It is important to make sure the camera is easy to control, can see what needs to be seen and transitions smoothly between any set positions it may have for things like cutscenes.

            Firstly, you need to determine where you want to mount your generic gameplay camera. For this blog I’ll demonstrate a basic third person camera. So the camera needs to follow the player and turn with them. The easiest way to do this is to create a virtual camera boom, attach the non-camera end to the player and position it so that the view will look over the character’s shoulder at what is in front of them. If depicted it would look something like this:

(Except the person would be facing the other way, the camera would be looking down at them and the boom wouldn’t have anything supporting it)

            Now that the camera is mounted, you need to determine what it can see, this is done by creating a frustum for your camera. When visualized, a frustum looks like this:

Now to quickly define the more important parts of the picture:

The (px,py,pz) represents the camera’s location

nearDist is the distance between the camera and the near plane

the near plane is closest point where an object can be to the camera in order to be rendered, anything before this plane is not rendered

the far plane is farthest point where an object can be to the camera in order to be rendered, anything beyond this plane is not rendered

farDist is the distance between the near and far plane, anything the falls within this will be rendered and displayed via the camera.

By defining the parts of the frustum, you can easily determine what space your camera renders and what it doesn’t.

So now you’ve got a basic gameplay camera with a defined frustum that follows your character around watching over its shoulder. That’s okay for gameplay, but what about cut scenes? Probably not very effective, so let’s try something else. We can place nodes within the world for a camera to use as its position. These nodes can also store orientations, so the camera knows which way to be looking. When a cut scene starts, the camera changes its position to the node and the player can view the events from there. However, static cameras can work in some cut scenes, but sometimes a moving camera is required. The easiest way to do this is to set up a bunch of nodes along the path that you would like the camera to follow. Then you just interpolate from one node to the next at whatever pace the cut scene calls for. After this the camera can move on to another cut scene or back to its usual gameplay state following the character around.

If you are designing your level/cut scene in Maya, you could create a spline curve for the camera to move along. This gives a much smoother movement then that generated from interpolating between nodes.

Well now that I’ve brought up Maya, let’s talk about some of the cool gameplay cameras you can create using nodes and splines. If you are using Maya for your level design, you can place nodes and splines along the characters path (works best in fairly linear levels). Based on the characters position, you move the camera along the splines/node paths so that the camera keeps the player in view as they move. This gives designers much more control over what the player can see and allows for some very interesting visual effects. 

[someblogontheweb]

AI

            Welcome to this blog on AI in video games, I’m just going to say up front that this blog will not cover navigation in depth, as I believe that topic deserves a post all to itself. So I’ll be focusing on the other aspects today. Without any further ado let’s get into it.

So, what is AI?

            AI stands for Artificial Intelligence. It is a term given to any automaton (in this case a computer) that can display a human’s level of intelligence. While people have been attempting to develop “true” AI for a very long time, nobody has yet succeeded. There are several tests that a potential AI would have to pass in order to be considered indistinguishable from human intelligence (ex. the Turing Test: http://en.wikipedia.org/wiki/Turing_test for those interested). At this point it is only possible to simulate intelligence, but it is generally in very narrow and contained examples.

Well that’s all well and good, but what does it mean for games?

            It means a lot of things. Since no true AI exists, we are limited to programming behaviours for the entities in our games to perform. This gives us nearly full control over what the entities do in the game. I say nearly because nowadays the AI’s in games are designed to be dynamic so that things won’t play out the same way multiple times in a row if the AI chooses different paths. Which means in essence that we have started programming ways for us not to have total control over what the AI do in real time. Scripted AI that always behave the same way still have their place in games, as they require less processing power than dynamic ones. However, in my opinion at least, in games that have both scripted and dynamic AI’s, they should be kept separate. I’ve experienced a few immersion shattering issues with scripted enemies not dying from repeated headshots, whereas their identical bad guy companion standing a few feet away keels over if anyone so much as sneezes in his general direction.

            Back on topic, the addition of dynamic AI’s to games allows for a whole lot more replay ability of the game, along with making a much more immersive experience for the player. A great example would be the AI Director in Valve’s Left 4 Dead series. (http://www.valvesoftware.com/publications/2009/ai_systems_of_l4d_mike_booth.pdf, it’s a good read, and I’ll be talking about some of the points in it). It is important for the allied survivors to feel like you are playing with other people (for the most part, they still prioritize giving you healing items). They went as far as to simulate reaction times and senses to make their shooting behaviours more realistic. They did hamper them by giving them very predictable decision making behaviours. For example, when a player goes down, the AI will instantly prioritize saving them as opposed to dealing with the threats first.

            Valve breaks up the allied AI into two main parts, which they call the Main and the Legs. The Main handles the more important decision making in terms of aiming, shooting and interacting with the world. This handles most of the behaviour that the AI exhibits in front of the player, which attempts to simulate believable (although hampered) human behaviour. The Legs handles movement decisions based around keep the AI near the party. If they wander off too far from the group it wouldn’t accurately simulate the safety in numbers mechanic that the game is supposed to promote. The AI behaviours were actually taken from watching people play the game and breaking down what they do into the basic behaviours and simulating those in the AI.

            Many of Valve’s popular games (Team Fortress 2, Counter Strike, ect) usually make use of very few maps at launch. Playing these same maps over and over again would get boring very quickly, except that it has a dynamic experience because the enemy team does not follow the same path every round. This is because the other team is made up of players just like you. However, in a game like Left 4 Dead which does not feature enemy players in most of its game modes, it cannot rely on them to create the dynamic experience. Instead they created what they call the AI Director. The Director is responsible for the spawns of weapons, equipment and health that are in the level, as well as the hordes of zombies that spawn. This turns a largely single player/co-op experience that could be very predictable into something that keeps players on their toes no matter how many times they play through the levels. The Director procedurally generates the enemy spawns based on a huge number of factors, which prevents players from memorizing the movements and spawn patterns of the enemies. To not break the experience by making enemy spawns visible to the player, the Director breaks down the nav mesh of the level into chunks. Depending on the player’s position in the level, relative to the chunks, makes the chunks capable of spawning enemies or pickups. Only chunks within a certain distance/visibility of the player need to be active, so other parts of the level can be ignored until the player gets closer, and this saves processing power which can be used to give a smoother player experience (or swarm them with zombies). Chunks can also store information about the enemies that are in them, and re-task those enemies based on what is going on nearby. If a chunk is about to leave the active area, the zombies in there can simply be moved as opposed to destroyed and then recreated.

            The Director uses various events to estimate the intensity of what the player is feeling at a given point. Using what is available to it, the Director aims to create spikes in the intensity by releasing swarms of enemies after the intensity has leveled off for too long. This will spike the intensity of player emotions, hold it at that peak briefly, and then allow it to drop, giving players a chance to recover from the emotions and what just happened in game.

            While the Director procedurally spawns enemies, it can only spawn equipment and pickups in designer specified places. This allows for players to learn the locations of where they can receive aid, although the Director decides which pickups will actually spawn and in which groups.

            That is a breakdown of the AI Director in Valve’s Left 4 Dead. While doing this blog I have become incredibly interested in the designs and effects that AI can have on games and will continue to do readings on it if I ever have free time.

[someblogontheweb]

Benefits of Scripting in Game Engines.

            Adding a layer of scripting on to a program allows for users to customize and modify their experience with the software. A basic example of this would be the Visual Basic scripting you can do in Excel. These modifications can be macros or functions that make completing a lengthy and repetitive task in Excel go much faster.

            The use of scripting in games and game engines behaves in roughly the same way. You write various pieces of code to alter what the engine or game does, adding your own touch of customization to it. Scripting languages are generally high level and simple to use since most of the work is done where the scripting language is read by the engine.  There are two main kinds of scripting languages; interpreted and compiled. Compiled languages need a compiler in order to translate the code into a machine useable state and then the CPU can make use of it (much like the programming we are used to). Interpreted languages are a bit different. They program will either read it at run time or it will be pre-compiled into byte code and fed to a virtual machine for use instead of the CPU. Byte code is platform independent, so it using interpreted scripts can help save time when working across multiple platforms. Virtual machines are also easy to port to different platforms.

            One of the best parts about scripting is that altering or loading new scripts does not affect the engine’s source code, so you don’t have to recompile the engine. This really speeds up parts of the development process because you don’t have to wait for all of the engine code to be recompiled if you just changed one small thing. The scripting language allows for rapid changes to be made and tested in a very short period of time (comparatively). A good example of this would be when I was working with UDK in the past. There is built in scripting using Unreal Script and Kismet. Though I mainly used Kismet (very high level language), those parts of the development were noticeable faster than adjusting the lighting and geometry in the level. When you changes those things, it leads to a lengthy rebuilding process where the engine remakes the geometry, and then does all the lighting calculations. When I was scripting the AI I didn’t have to rebuild anything, I could just click the test player and see how the changes I made effected what was happening. Though that isn’t an example focused 100% on the code, it’s a very similar experience to have to recompile an entire engine (in terms of time).

            One of the more popular scripting languages is Lua and it has been used in many games to date. I first heard of it many years when I played Garry’s Mod. It’s a mod for the source engine that allows you to play with the assets from the source engine in a physics sandbox. Lua scripting is used to give the user access to the various tools, and to allow for mods to be created for the game, adding many more features than come default with the game. Since it is so lightweight and portable, I wasn’t surprised to find out that many other games used it as well. Since we will probably be using Lua as the scripting language in our game this semester, it would be worth my time to have a basic knowledge of how Lua works and not just how to program in it.

            From the information gleaned from the slides and the textbook, I think it may be possible to do the AI in our game using Lua scripting. By placing nodes in Maya, loading the file into the engine and having the scripts references the nodes as points  to avoid in the world (as they would represent hazards), the AI would behave in a more interesting manner as it navigated the world instead of just bee lining for the player. That’s the real problem with AI, its really easy to give them a behaviour that just beats the player, the difficult part is making it look realistic and letting the player have a fair chance against it. Using scripting would let me change up the behaviour quickly enough to be able to balance a good AI without spending excess hours waiting for the engine to constantly rebuild itself.

            Doing the readings for this blog taught me a fair bit about scripting and gave me some ideas for the game, so I’m going to go try implementing those, and hopefully I’ll be able to blog about my successes in scripting AI in the near future.

[someblogontheweb]

PVP Fight

Today I’ve decided to change it up, instead of the regular lecture summary blog (PvE), it is time to do some PvP-ing. It’s time to review somebody’s Portal 2 level. The level in question is Poly Path, made by Thomas Galati.

To start is a couple screenshots from when you first enter the level.

From these pictures you can clearly see that the entire puzzle is contained within one room. This was an apparent design choice to put everything the player needs to solve the puzzle in one place and have them figure out what needs to happen with the individual pieces as opposed to segmenting the level into different rooms. One of the issues with the level I noticed right from the start is that one of the cubes was constantly bouncing off the ground into the water. It then respawned and followed the same path, winding up in the water again. While it did fix itself after a minute or two, this is definatly preventable. You could adjust the positions of the droppers, or add a fence cage in a U shape around where the cubes spawn. The cage would still allow the lasers to pass through while simultaneously preventing the cubes from constantly falling into the water. The area for the cage is outlined in yellow in the next picture.

I can understand why the idea may seem a little weird, seeing as it appears to add an extra level of safety to the area where the player is supposed to be able to fall into the water, but I did the jumping part of reaching the cubes from between the two sets of lasers. Since the lasers cause a marginal amount of knockback when you make contact with them, they essentially act as dangerous walls for the player to not fall off either side of the platform and only have to worry about the jump straight ahead.

Next up is one design decision that really caught my eye.

After completing the cube retrieval once, the player has the option to use that cube the raise platforms, making subsequent cube retrievals much easier. I thought this was a great idea because in order to activate the platform the player has to prove that they understand how to retrieve a cube from the centre platform. After the first time, the simple task becomes repetitive and slightly unnecessary for the player to complete 3 more times. Having the platforms acknowledges that you can complete that part of the level, and thus makes the following times much easier. However if you are looking for a slight added challenge there is no need to raise the platforms, allowing players to add a little extra difficulty to the level.

The rest of the level is fairly straightforward; you need to move cubes around the level to various buttons in order to activate the funnels that will take you to the end of the level. One button is easy to reach, one requires you to jump and put the cube on the ledge above you where the button is, and the last requires you to use falling momentum turned into sideways momentum in order to land on an elevator that will take you to the button. I had a bit of an issue with the elevator one this time around. I’ve beaten this level in the past, but today I encountered a problem that unfortunately ended up breaking the level so that I couldn’t complete it.

The way that the elevator is set up allows for this problem to occur. When I landed on the elevator I turned while holding the cube and it got stuck in between the platform where the button is and the elevator. The elevator promptly froze in place and I could not remove the cube. I imagine that this is one of the fringe cases as I doubt that this would happen to many people, I just happened to be so unlucky.

As for my suggestions to fix the possibility of this problems happening again, the easiest would be a button somewhere in the level that causes the cubes to respawn. Another solution would be to extend the button platform down to the water so there is no gap for the cube to get stuck in.

On the whole I very much enjoyed playing the level. It is on the shorter side in terms of length and the easy side in terms of difficulty, but it presented an interesting puzzle that I felt good about completing.

[someblogontheweb]

Lecture Summary: Living Structures and Visual Experiences

Another week, another lecture summary.

            Video games are entirely based around visual reactions. If you push a button on the controller or start interacting with something in the game, you expect some kind of a visual response to show that what you are doing has an effect in the virtual world. One of the most basic of these are the visceral reactions. These play on our primal instincts by giving violent and graphic visuals to the actions we take. They work best when people are scared of or angry at whatever they are attacking or being attacked by. These reactions use our primal instincts to help reinforce the feedback.

            A very important aspect of games is their visual direction. All games choose an art style to define the look of the game. The style defines not only what the assets will look like, but how the environment should feel, how the buildings are objects are laid out in a level. The levels should have a personality to them. It helps create memorable locations in your game. For example, the first one that jumps to mine is Ravenholm from Half Life 2. There was such an abrupt change from the lab environment to this town of horror. The first time I played through it I was actually very scared and I had to take a break from playing just to calm down. There was one living resident of the town, and he embodied the feeling of the town. He was dark, creepy, and just a little bit insane. He was a part of that town, and would have been incredibly out of place if he was anywhere else.

            This lecture focused a lot on creating living structures using Alexander’s 15 Properties. These properties help to give your level its atmosphere and feeling. They can turn a very bland environments into very interesting ones. Looking at this list of properties, it reminded me of something I watched a while back about the series Firefly. It was some of the cast and crew talking about how their ship, Serenity, was like the 10th character in the show. Although I didn’t really realize it the first couple times I watched the show, the ship really does have its own personality and distinct role in the show. The ship also displays many of the properties of a living space which may or may not have been done intentionally by the creator or not.

            Looking back on a lot of games I’ve played, it’s fair to say that the more memorable levels/areas/worlds were ones that displayed more of these properties than the others. I’ve mentioned Ravenholm already as an example, and Serenity was enough of a living structure to be considered its own character. There are a few memorable places I would like to talk about briefly so I’m going to list them and do a quick note on each

Windfall Island from Wind Waker. This peaceful little island is where you end up early on in the game after nearly drowning in the Great Sea. The most notable thing about the island is the huge windmill in the center of it. The island is quite calm most of the time, and all of the residents are quirky in a memorable way. Later in the game you return to the island as part of the story, and the unnatural darkness and storm clouds make the island feel almost wrong since its generally such a cheery place.

Columbia from BioShock Infinite. At first glance the city looks like a very happy place to live. However you quickly start to notice all is not as it seems. Things quickly take a turn for the dark and twisted and before you know it the whole city is falling apart. There is also a huge change in feeling when you move to different parts of the city, making it feel a little alive.

The Star Wars Universe. While not exclusively a from a game I felt the need to mention it just because of how deep and detailed it is. The universe has kept me interested for many years and I probably know more about it than I should. With new games, books and movies coming out the universe will keep expanding (hopefully for the better).

Anyways that’s this blog done with. Take it easy.

[someblogontheweb]

Lecture Summary: Play Spaces and Level Design

            This is actually kind of exciting. After years in this program I finally get to learn about what I came here to do. Level Design. The past few years I’ve gotten a chance to do a little bit of it in the various games we’ve made but never really had a chance to go in depth. Now there are quests which give me the chance to actually experiment with it and finally get back into it. That said, time to summarize the lecture.

            Game designers create the mechanics for use in games. It is up to the level designers to create the way the user interacts with these mechanics within the game. I agree with the quote in the slides about level design being about taking theories behind gameplay and putting them into action. All the things I’ve heard about level design from these lectures and other sources don’t really sink in until you create something that uses them and seeing how people react to it.  Playtesting is the most important part of level design because players come up with ways to play the game that the designers don’t think of.

            One of the most basic principles of level design is teaching the user how to use a new mechanic when you introduce it. Nothing is more frustrating than getting a cool new piece of equipment and not knowing how to use it. That being said I’m sure there is an argument for giving the players equipment and not teaching them how to use it, but still giving them an environment in which to learn what it does at least at a base level. When you set out to teach a player how to use a game mechanic, it is important to make it clear how it works. Then, in later parts of the game, make players use the same mechanic in a different way. That helps keep things interesting and keeps the players thinking.

            The player needs to understand their capabilities and limitations in terms of their abilities and how they can interact with the environment. This should be taught at a base level early on, while leaving the finer points for the player to discover later. Another important thing for the player to understand is how the enemies behave. This is important so the player can make a plan of how to defeat them. It is also important for the player to understand how to get rewards out of the game. If you kill an enemy, maybe he drops loot, or maybe just some ammo for the gun he was using.

            It is important for game mechanics to stay the same. If the base feature is constantly changing chances are the player will become frustrated. You can think up creative ways to apply the game mechanics all you want, but the mechanic should stay the same throughout. Teaching a mechanic should be done in a safe environment. While the environment doesn’t need to seem safe to the player, it should be designed in a way that doesn’t punish the player too harshly for failing at using a new mechanic. For example, escaping Vaas’s compound at the start of Far Cry 3. The game teaches you how to run, jump and climb while you are being shot at. Even though the situation feels unsafe, it is controlled to give the player time to learn the basics of the game. Continuing this example, this sets up your main goal for the game, which is to save your friends who were captured by Vaas, and to get revenge on him for killing your brother.

It is necessary to plan levels with contingencies in mind. It is very possible that either the level itself or the mechanic you based the level around will be cut and you will have to make adjustments, either to introduce a mechanic in another part of the game or to replace the mechanic that made your level work with a new one in order to still have a functioning level. While this can be a pain, it is necessary, otherwise part of the game will be lacking and may throw off the flow of gameplay.

All the types of levels (linear, semi-linear, and non-linear) have their advantages and disadvantages. The tricky part is figuring out which one fits your game the best and running with it in a way that plays to the type’s strengths.

With this as a good refresher, I’m ready to get back into designing levels that are interesting and fun to play.

[someblogontheweb]

Lecture Summary: Digital Prototyping

            The purpose of digital prototyping is to quickly and effectively test out a few core gameplay mechanics to see how well they work. They always focus on one or two gameplay mechanics because any more and you might lose sight of what you are testing for. The most effective prototypes are simple and to the point. There are various different types of prototypes, each focused more around certain aspects of the game, whether it be aesthetics, game mechanics, kinesthetic or just seeing how well the technology behind your game works.

            Each prototype you make for a specific game mechanic should be focused on that mechanic almost entirely. Obviously if that mechanic requires some other mechanics to work well, you should include those as well otherwise it may not feel right when prototyping. If you want to test how you’re the bullet spread of a particular gun in your game, set up a shooting range with some targets at varying distances to make sure the gun is as accurate as you wanted. It’s simple and effective. There isn’t really a need for more mechanics.

            When prototyping the games aesthetics, there are quite a few things you can do. To start, almost every game ever made has concept art. It helps the artists figure out what things are supposed to look like and the rough style that they have to create the assets to match. For things like cut scenes, you can make storyboards. The storyboards can show the various camera angles, what will be in the shots and (if needed) the rough dialogue that will be taking place during the cut scene. This makes sure that the scene looks sound on paper before it is sent off to be animated and rendered. Story boarding can remove a lot of possible wasted time for the animation team that they would spend redoing things that could have been solved beforehand. As for prototyping a user interface, this can be done on paper until the artists determine a UI that looks appealing and gets all the information across. Then to make sure it looks proper in game, they could piggy back the UI on to one of the game mechanic prototypes. That way you can get a decent idea of how the UI would look during gameplay, and if it fits with the game’s art style.

            Prototyping the Kinesthetics of a game just breaks down for how the game feels when you play it. If the controls are really sluggish in a shooter, it likely won’t feel that fun to play. It is also a great way to test various control settings and layouts. Most console games have multiple button maps, which change what the buttons on the controller do. They also have things like the stick sensitivity, which controls how fast the sticks allow your view to move. Some people like that really high, others (like myself) prefer it a bit slower. It would be really good to set up a prototype to make sure that the various button maps worked well overall, and the other options allow for a wide range of users to be comfortable on.

            Designing control schemes is difficult because they need to be easy to pick up and be comfortable for the user. The design of the controller also needs to be taken into account, because forcing players to contort their hands awkwardly doesn’t make for a fun playing experience.

            As for the tools available for producing these prototypes, there are quite a few available. Unity and UDK are the easiest ones for us as students to access. From personal experience I know that the UDK is pretty easy to work with and with little effort can definitely be used to prototype certain gameplay mechanics. Though in my opinion it works incredibly well for quickly turning a level idea into a basic level design. Then you can have people try it, and get feedback to change it into a really good level idea, which you can take to your own engine and turn into a real level. 

Whew, that was a hefty day of blogging. I'll likely be back at it within a few days, so stay tuned!

[someblogontheweb]

Lecture Summary: Game Systems

            All games have systems in place to control the flow of gameplay and how the players interact with each other. These systems are made up of objects and the interactions they have with other objects and players. These interactions will help define the way the game plays and how the players behave. A simple version of this would be the money in Monopoly. It controls the way the entire game plays. It controls how many properties (resources) a player can purchase. Players can also exchange the resources between each other, trading them for other properties or money. Running out of money means that you lose the game. The money defines the most important system in the game, because it also changes how players interact with each other. Players with more money are more likely to be able to get what resources they want. I’ve noticed this working when I’ve played monopoly. The worst feeling is being bullied around the board by people with all the money and properties, because you realize it’s not about winning anymore, it becomes a question of how long can you stay in the game. This gives a good example of a system, and more specifically a simple economic system. There are more types of economies, each type appeals likely has a different appeal to different players.

            While the systems can be design and the behaviours they create can be theorized, they can never truly be predicted. Not everyone will react the same way given the same set of circumstances. The feedback from making a decision can be either positive or negative, and it does not need to make itself apparent right away. The feedback can come later when an event happens that, while completely unpredictable when you made the choice, confirms that choice to be either a good or bad choice.

            The only way to make sure that these systems behave (roughly) as the designers intended is to rigorously playtest it with many different groups of people. It’s very important to use many groups of people, because people aren’t predictable in how they react to a particular set of rules. I’ve found this in the past when designing levels in UDK; however it was very prominent very recently when I was creating a level in the Portal 2 level editor. When I designed the level I was afraid that there would only be the way I designed to solve the puzzle, but I was happy to find out when the level was play tested that there were multiple ways to solve the puzzles. I also found out a part of the level that was far too based on timing and a little bit of chance, so I had to adjust that part. There was also a part of the level that broke when interacted with in a certain way which I didn’t notice when I was designing. That really drove home the need to playtest all the systems in order to make sure that you can’t break them, and yet still has some flexibility in order to allow for various ways to solve a problem.

[someblogontheweb]

Grind Quest: Objectives

To start I guess I should list 10 of the best games I’ve ever played and a little bit about what the main objective was in each of them.

BioShock Infinite:

Rescue Elizabeth from the floating city of Columbia and fix your past mistakes.

Alice: Madness Returns:

Explore Wonderland in hopes of finding something that can stop the train that has been destroying it.

Far Cry 3:

Help the islanders remove the mercenary forces that have recently invaded their lands. Help your friends fix up a boat so they can escape the Island.

Mass Effect:

Explore the galaxy looking for technology and information that can stop Saren and the Geth from bringing about the return of the Reapers.

Dragon Age Origins:

Gather allies in order to help you defeat the oncoming blight.

Grand Theft Auto 4:

Take jobs from various people in order to earn money and build a life for yourself in Liberty City.

Red Dead Redemption:

Perform tasks for whoever is hiring in order to restore and maintain the family ranch and protect your family.

Wind Waker:

Explore the Great Sea looking for the Triforce and other treasures that will help you stop Ganondorf from returning.

TES IV: Oblivion:

Explore the world in search of treasure, completing quests along to way to become one of the most prominent people in the land. Prevent a Daedric from turning the land into a Hellish environment.

10.  DayZ:

Stealthily explore cities, military outposts and many other locations in search of supplies that are needed to survive the zombie infested lands. Decide how to deal with other players you find, be it befriend them or kill them.

Judging by this list the kind of games that appeal to me are incredibly immersive games. I’ve always been drawn to incredibly deep and complex universes (like star wars, even though it is not listed). I really enjoy watching a story unfold in front of me in these settings. If I become attached to the characters in the game it means that I care what happens to them. I believe that all important and interesting characters in games deserve some kind of an ending. Doesn’t have to be a happy ending, but they still need one rather than them just disappearing and never being heard from again.

            Most of the games I enjoy have at least some open world elements. This is because I don’t ever like feeling stuck in games. Some people thrive on the challenge, I do not. If I’m playing the “story” in Battlefield 3, I don’t like getting killed 20 times in the same hallway and sitting through a lengthy loading screen every time. Whereas in more open world games, if I get stuck, I can go do something else and come back to the part later, possibly being better prepared but definitely not feeling as frustrated.

            In terms of settings I think that the list shows that, in terms of settings, I don’t have any strong preference. From crazy fantasy to realistic cities or distant sci-fi settings, it’s more about how immersive the universe is that what kind of genre it is.

            I feel it important to say a few things about (what I feel is) the outlier on the list. DayZ. It is a mod for ARMA 2. It does not have any story to speak of, and it can be incredibly frustrating at times. The reason it made the list is because of how incredibly immersed I get when playing the game. I’ve actually caught myself whispering over voice chat to other people even though the volume of your voice has effect on the zombies. I’ve been scared when creeping around abandoned buildings and jumped out of my chair with a bit of a scream when I round the corner into a zombie. This level of immersion is achieved with no back story, which I find absolutely amazing.

            I suppose if I had to choose a small range of game types that appeal to me, it would be any extremely immersive single player experience, or games that you can have a lot of fun with when you play with friends.