Weekly Report (May 3)

Yeah, finals week!

This week I made the FMZs to the main level convex using the python script.  Shea helped get the level into working order afterwards because the zones were reordered, untextured, etc.

Here's a summary of the important things I did this semester (I'm excluding things that I either think are too small, or just plain forgot about; haha, you can go back to look at the old blog posts if you want):

• I implemented a recursive next hop forwarding path generator that automatically took an fbx's contents as input through the content processor using naming conventions.
• I also implemented the convex zone classes and made my own algorithm for checking within the zones; I thought it was pretty clever.  That class was used in vector fields, Portals, and Free Move Zones.
• Made the massive terrain level, portals, and convex zones (didn't add the items to them).
• Modified a Blender 2.4 python script to work with Blender 2.6: it generates convex hulls, but it had been using horribly outdated APIs--I had to sift through the new and old APIs to get it working.
• Added non-player character factions (player enemies vs friends--though it wasn't fully utilized since there are only players and sharks!) and behaviors (such as attacking, retreating, moving to specific zones or places, etc).

Wow, the blog crashed 4+ times while I was trying to make this!  It seems to crash while using Ctrl and the arrow keys to skip over words while going backwards on the bullet list--yep, confirmed; you're welcome Blogger.

Jason out

Weekly Report

This past week I spent a great deal of time in Maya. I created several levels of terrain, that could eventually be used in the game. The part that is taking a lot of time is creating the zones for the levels within the landscape. I've found it is quite difficult to make the zone meshes match up with the terrain. The best method I've found so far is to make the mesh larger than the terrain, and then continually shrink it down until it conforms to the same shape as the landscape. It takes a lot longer than I thought it would.

I've also creating some different objects that can be placed into the scene like different varieties of plants and rocks. I also made a few objects that are meant to be diamonds or gems. They should be able to be collected throughout the level. The idea is that these objects can be sold at the store in exchange for useful items to put on the ship.

Weekly report

This week I worked on globably intergrating the water current to the levels. I had a couple problems with the normals and the direction but now it's working. We are also going to add current to the puzzle in the game.

Weekly Report (April 28)

The convexity of the FMZ's is problematic; I couldn't get the convexity script to delete the extra vertices, but I realized how I can get rid of them--if I use Blender's face select, then I can just copy all of the faces into a new object in the scene, and then the vertices without faces will be left behind!

I can do this after my Monday final(s)--a two part final for one class.

So, this week, I discovered that the game sometimes crashed on exit.  At first, I thought it had something to do with the sound files, but I turned them off, temporarily, and was still able to reproduce the crash.  So, then I checked the exit function.  It was still going through all of the Draw and Update code after "game.exit()" was called.  I figured that it was releasing some data asynchronously, and then causing the memory errors.  So, I set a quitting variable to true, allowed the game to run through its final frame, and then quit at the start of the next frame in both draw and update.  Not sure if it has totally been solved, it seems like there could still be cases when it goes horribly wrong.

The sharks had some movement adjustments--I was playing with their speed because they are so little threat to the player.  If you set their maxSpeed, you can make them faster or slower.  I had it double what we were using at the end of Friday, and I think that may be sufficient.

Weekly Report

Last and this week mainly thought about how the current would be use in the puzzle, at first i wasn't sure what could be done. But now i have a clearer idea of how we could put current in the puzzle Mathew is working on, possibly on the sides that way the player would have to find a way to get to it.

Weekly Report (April 21)

Well, that went well.

I added smoother controls to the sub and diver to make full use of the xbox controllers.

Other than that, I've been finding and fixing small breaks in the NPC code; for instance, the sharks would appear to get stuck whenever their movement curve's length had to be approximated--although, they were just moving really slowly--for that, I simply improved the approximation for their curve's length.

I've also been trying to change the shark's movement--I don't think I had the weighted location picker working correctly, and I need to test my new version before I know it is working correctly.

Jason

Andrew Harmon - Weekly Report

This past week or so I've been focusing on the music and soundeffects for the project. On top of composing the different musical scores, I also was able to load them into the project, and get the music to play when the game begins.

This is a link to a great article I used to get the music or sound effects to play in the project. http://msdn.microsoft.com/en-us/library/bb195053.aspx

The main steps are to declare a sound effect or song. Then the sound file must be loaded into the project. And then you must have a place in your code where you type mySoundEffect.play().

This past week I haven't had a lot of time some implement some of the puzzle ideas I had, I just started by putting a small simple puzzle that consists of moving blocks around in a certain way to get to an item. I am still trying to get some other ideas of a slightly harder version of that.

Weekly Report (April 13)

Friday the 13th!

Anyway, here's what I can remember that I've accomplished this week:

The sharks don't randomly disappear anymore.

I implemented several new NPC behaviors:

• When they are not attacking something, sharks are more likely to continue travelling through portals that they are facing, so they won't keep going back and forth between zones. When they reach a destination, it weights each of the portals based on the angle from their facing direction, and then it randomly picks one based on the weights.
• Running away is now possible--sharks give up after their would-be prey is out of range (20 meters, right now).
• Smaller fish (if there were any!) will run from bigger fish.

I also compressed those .wav files for the music into MP3's so they wouldn't be 100+ megabytes!

There were some other relatively small changes, but I can't remember them! Oh well!

Jason

April 13

This week has been rather hectic for my stuff. We finally got the blocks fixed, and the wall collision sort of works on both sides now. However, the camera collision still isn't completely finished. It works, but only if "up" to the player is Vector3.Up, and here's why:

The way the collision basically works is I set up a Ray that points from the player's position toward the camera. I find all intersections with objects along that ray for infinity, then I set up a temporary position vector that sits on the collision point (the one that my code decides is the appropriate one to use, but that's a different story). I then check the distance from the player to that position against the camera's constant offset. If the offset is larger, that means the camera IS actually clipping through the plane and needs to be fixed.

The problem is, I don't want to just set the camera's position to be the temporary position, because if the player is completely against a wall facing away from it, the camera would then be inside the player. My fix for this is that I modify the temporary position's y value to be the camera's actual y value, then set the position to be the new temporary position. This will ensure that the camera stays at the same height. But this only works when "up" is Vector3.Up, because I'm modifying just the y value of the vector, when I should be modifying some component based on player.world.Up. Since player.world.Up is a unit vector, multiplying it by a position vector singles out that "component" of the position, but I'm unable to modify that component.

What I'm wanting to do looks like this when written out:

tempPos * player.world.Up = Position * player.world.Up


Although, this is an illegal statement (obviously) and algebraically it doesn't work either.

So, to fix this predicament, I got rid of the Position member of the Camera class, and replaced it with a World Matrix. We still have a position within the matrix, World.Translation. But this way, it is easier to translate multiple times since the Matrix multiplication is handled for me, and I don't have to worry about modifying certain components of a Vector3.

After that, I added another list to my code that keeps track of collisions. So now I have I list that keeps track of the distances away from the player, a list that keeps track of what kind of object that is colliding, and now a list that stores the actual Plane that is being collided (so I have access to its normal and other useful things).

So when I get to the part where I need to fix the camera's position, I make another Ray that points from the camera (specifically, where the camera would be if it didn't care about collision) in the direction of the Plane's normal vector. This way, I should be able to calculate the distance from the camera to that plane and translate the camera's position the calculated amount along that vector so that it is no longer colliding. The problem is, the code isn't working and I can't seem to figure out why.

EDIT: I think I figured out the problem. I think the spring camera was breaking it. I changed Camera.Update() so that it takes a Character instead of the character's position vector and world matrix (which was redundant anyway), then after preferredPosition is calculated, I call Camera.Collision() (which takes the Character as a parameter) before calculating the actual position of the camera, and I changed the code inside of Collision() to modify preferredPosition instead of the actual World matrix. This seems to have fixed the issue. I'm not on campus so I can't commit, but I think the issue is solved.

Since my last blog post I've continued making adjustments and changes to the interface. I created some images that I added to the playing screen like the treasure and weapon icons. There is now a shop in the game, though you cannot buy anything from it yet. You are able to go to it from the map menu though. You can toggle between the shop, save, and quit button. Which ever button you are over will be larger than the other buttons.

I've continued to compose some music, and have started adding them to the map page and the different levels. There is still more work to be done in that area, but things are progressing. 

Weekly Report ( week of the 26th)

The week of the 26th through the 30th wasn't as eventful for me, I spent some time thinking about some puzzle ideas that could be implement and as soon as Jason finishes the levels in maya, where we would have a bigger area to put blocks and other objects.

Weekly Report (April 7)

Hello again,

Aside from re-fixing some of the terrain, the NPC's got a few important fixes. For example, I had forgotten to deactivate the completely incompatible action states whenever I activated a new state--fixing these issues solved a few odd cases where the sharks would not attack until after they reached a portal destination because their states were incorrectly set.

Setting the NPC's direction based on the interpolated tangents was turning out to be a major bust--attacking and arriving backward just wasn't looking good! So, I made them face their movement direction.

The current issue is that the sharks decide to just disappear sometimes! They have the same position as the sub, and they are not being drawn... I really don't understand why that would happen. It isn't like their current zone is null or their health is 0.0f or anything that obvious--they are even still on the list of FMZ residents! Super

Jason

Weekly Report (March 30)

Hi, Jason here.

Making the levels well is going to be difficult--having convex zones will inhibit the process much more than I had anticipated. I made the larger "massive terrain" fbx this week. Maya and Blender don't get along well at all, but I've learned all of their "handshakes." Blasted red tape!

For instance, I learned this one today, when handling an obj from Maya within Blender, some meshes will have a "Duplicated Faces" option set to "Group." It's probably if you duplicated the mesh at some point. Make sure they are set to "None," or nothing will export.

There were some others that had to do with the XNA options--the labs only have Blender 2.5, but Blender 2.62, which I carry on my jump drive now--lol--has XNA helper options when you export an fbx. In Blender 2.5, the scale was out of whack when I tried to import the fbx into Maya, so I assumed 2.62 options fixed it.

After all of my classes ended today, I went back to the labs and got the massiveTerrain.fbx loading--it wasn't working because the naming convention was different than it said it was in the code's comments. The scene looks really dark for some reason, and I suspect it has to do with the fog shader.

I can't remember the every last little fix I made to the NPC and Gameplay classes--I was only focused on those changes on Monday through early Wednesday.

I definitely fixed a few problems in the convex hull script--the other script I had found ended up being even more sensitive than the first, even though it could be loaded as a plugin. Here's an updated version, it handles the process of removing extra vertices slightly better, but it still has issues!

http://www.pasteall.org/30539/python

Later guys.

This week I created some more images using photoshop, and started trying to incorporate some of these images into the game, hopefully giving the game a more appealing look. For a good tutorial on creating buttons, here's a youtube video I found.
http://www.youtube.com/watch?v=niHsjUha-2o

A dynamic healthbar has been added to the game. Right now the sharks pretty much suck the life out of you the moment they touch you, but it works. I've also included a map icon to the bottom of the game screen. This should only be visible at certain points in the game, and is an indication that you are at a place where you can leave the level and return to the map.

I've also been working on turning the images that I've created into buttons. I create the buttons as textures, and then load the textures. In the draw function I create a rectangle with the x and y coordinates, as well as the width and height of the button.

I'm also working on creating the map, and the 'x' that mark the location of different levels. Soon it should be possible to choose a particular 'x' (as if it were a button), and be able to jump to that level.

I also created different colored buttons based on whether the button is currently being pressed down or not.

Weekly Update (3/30)

This week I finished the camera collision FINALLY. The problem I was having was that if the character was in a FreeMoveZone with puzzle elements (walls and blocks), I was getting that most of the time the camera was colliding with walls and/or blocks even when I knew that wasn't the case. I went back and examined the code thoroughly for the (insert large number here)th time, and I discovered that I was just checking for an intersection with a Plane object, which extends to infinity; I never actually checked if the collision occurred on the bounds of the object itself. So after fixing that, the camera collision works as expected, it only collides with FMZ boundaries if there isn't a FMZ behind it. There are spots where it will, but that is because the boundaries of the adjacent FMZ don't extend as far as the one the character is currently in, so the code only detects one collision instead of two collisions.

The way my code works is like this:
I create a list of Vector3s that will hold the vertices of every relevant object at that time. The relevant objects being the current FMZ and everything inside it, as well as the adjacent FMZs. I also keep track of where in the list does the object type change. What I mean by that is I add the vertices of all the blocks first, then a create an integer that holds the count of the list at that time, so that will denote when the WALLS start, and I do the same after the walls, because then I add the FMZ vertices to the list. I also keep track of how many vertices are in each type of objects. For example, walls have 6 vertices each, while the blocks have 36. This is important because when I check for collision, inside the loop I have another index variable that loops through how many indices the current object type has. That way, for example, if the camera is colliding with a block, it may be colliding with the front AND back faces, but since it is the same object, after it detects collision with the front side, we don't care that it is colliding with the back.

After I find all collisions, I sort the lists based on the collision distances. I then check the first collision object type. If it is a Wall or a Block, we stop there and update the camera position accordingly. Otherwise we see if there are an odd number of collisions. If so, this basically means that we are colliding with the boundary of the current FMZ and that's it, and therefore update the camera position. An even number of collisions (where the first collision isn't a wall or block of course) basically means there will be only two collisions. The first being the current FMZ boundary and an adjacent FMZ boundary. In that case we don't want to change the camera's position at all, because the player should have no knowledge of FMZs or portals, and if the camera collides with what seems like an invisible wall that they can move through, there's obviously something wrong.

This past week I've been doing a fair amount of work with photoshop. I've created some different backgrounds that can be used for the winning and losing game screens. Also, I've worked on creating a background image that can be used in the shop we will have in our game. Some of the menu screens were basically single background colors, with square buttons, so I tried to make those screens look better. I'm now starting the process of converting the images into interactive objects, like buttons, that have some type of function. (Like the ability to push a button, or select an object). That is likely what I'll be working on this week.

One thing in photoshop I've been doing a lot with is applying affects to texts. I've been experimenting with different shadows, sizes, bevels, highlights, colors, and dozens of other options that are available.

Weekly Report (March 23)

This week I've been working on getting the camera collision stuff to work properly. Our original decision for how it should work is this:

Find the number of collisions starting from the player and going toward the camera (and past the camera as well). If the number you find is even, don't do anything. Otherwise, perform collision at the FARTHEST point away from the player. This was working decently (except for a problem that still exists, I'll mention it in a bit), except if there are walls/blocks in the FMZ, they throw off the algorithm for the even/odd numbers. So my fix for that was that if it collides with a wall or block first, immediately perform collision with it and be done. That works quite well.

Now for the problem that I mentioned before. I don't know why it's happening or what is causing it, but if I move the sub to the FMZ that has the blocks and walls (I actually haven't tested it in other FMZs yet) I can position the sub in such a way that the camera doesn't collide properly and goes out of bounds. When I set up breakpoints to monitor what's happening, there are usually 4-5 collisions detected, most of them being walls or blocks. That makes absolutely no sense since there are no walls or blocks out of bounds. I am completely at a loss as of now as to why it's doing this, but I'll hopefully figure it out on Monday.

-Matthew Bryant

Weekly Report (March 23)

Friday!

There was a problem with the sharks getting "stuck" on nothing--they were really getting stuck on the diver, who, when reported inside the sub, was invisible and could not be collided with, but still in the FreeMoveZone's resident list. Now, the diver is not in any resident list when inside the sub.

I started the framework for "retreating" NPCs--it's almost done, but I had to stop and fix the above issue.

Jason

Weekly Report

The past week I spent working on the vector field simulation. I have made some changes to the vector field class, also had to figure out where would be the best place to generate those fields in the gameplay. I believe now it's working fine.

Weekly Report (March 18)

Hey guys,

Part of last week went into the NPCs' interactions and states, but it is still a largely untested design. This week, I'll be able to finish implementing most of it, and I'll still have a week left to work on fixing the inevitable bugs xD.

The rest of it went into collaborating with Shea on the weird Portal/FMZ issues we were having.

We should really consider how we want to have the NPCs spawn into the levels, though. Is there a limited number of fish or do they respawn?

Jason

Weekly Report - Andrew Harmon

This week I've been working some on the layout of the screens. Right now I'm working on the screen which will pop up when the player wants to view the map or visit the "shop", or quite the game. Later the images will have to be made into buttons that will do things when they are clicked with the mouse, but for now I've been working on the looks. I don't have the images with me right now, but I'll try to upload it early next week.

I did some work in photoshop, and I just thought I'd that one important step that I needed was to create an image where the background became transparent. Knowing how to do this is something that could be very helpful for many different projects. The important step to remember is that before using the magic wand, or lasso tool, you must create a transparent layer for your image. If you do not do this first, you will receive an error telling you that you cannot edit your image.

Here's a helpful tutorial on how to do this easily.
http://www.mediacollege.com/adobe/photoshop/transparent/background.html

Level Content

Andrew wanted some ideas of things to model for each level, so I'll get it started.

While modeling, keep in mind that one unit is one meter.

Generic valuables:

• diamonds
• emeralds
• sapphires
• pearls
• rubies
• gold coins
• artifacts/statuettes (plates, vases, little statues, etc)
• keys

The player items will need models as well.

Level 1 theme:

• Anchor with broken chain links.
• Small caves that extrude from the seafloor--they would serve as a place for some sea life to spawn from.
• Treasure chests.
• Sunken, worn bottles.
• Starfish--not moving.

Caribbean Creatures: Small fish!

I like the Caribbean yellowhead wrasse.

http://www.flmnh.ufl.edu/fish/gallery/descript/csharpnose/csharpnose.html

Then there is the less cool looking Cyprinodon‑scale eater (pupfish).

http://news.ucdavis.edu/search/news_detail.lasso?id=9852

The Caribbean Nurse shark was relatively small looking, and could be the sole predator for level 1.

Level 2:

This one is tough--we'd mostly need a million different plant-like things.

Refer to Google for "underwater kelp" and "underwater sea foliage."

It would need a larger, less sandy cave for NPCs to spawn from.

The larger sharpnose shark would fit nicely with the others, I think, but I am no marine biologist.

http://dsc.discovery.com/sharks/atlantic-sharpnose-shark.html

Level 3: A coral reef? Need I say more? I think we need coral, coral, and maybe coral--how about some coral?

As for fish--lionfish please: the poison spines are a good game mechanic.

http://www.msnbc.msn.com/id/38632799/ns/us_news-environment/t/do-your-civic-duty-eat-fish/#.T1_MiRGm9Lc

Manta Rays

http://en.wikipedia.org/wiki/Manta_ray

Whitetip reef sharks are also welcome in the reef.

Don't forget the Clownfish & Powder Blue Tang--lol :)

http://www.topnews.in/how-reef-fish-use-their-fins-fly-underwater-against-currents-248175

http://www.sciencedaily.com/releases/2007/07/070712135148.htm

Level 4:

The ship!

The ship could have any number of regular accessories:

1. Tables
2. chairs
3. (furniture)
4. picture frames
5. suspended light fixtures
6. radio equipment
7. telegraph/phone
8. ship's wheel
9. life preservers
10. fishing nets
11. swords (coat of arms on the wall)
12. trunks
13. bunk beds
14. clocks
15. trashbin, etc.

puzzle related:

• levers/buttons.
• a wheel that helps to open a door.

Sunken lifeboats.

Creatures: I'd like crabs, sea snakes, and eels for the diver to deal with with a harpoon gun.

(though I sure don't know where crabs/lobsters live!)

Level 5:

What fish would live here? Well, I'd make up a really nice sea creature to block the player's path--like a monstrous tentacle creature that lives in a dark hole in the wall.

And I can't seem to find those giant "things" that pretend to be a part of the seafloor, and jump up and eat passing fish.

Most of the terrain is rough rock, and it would not need much decoration.

Is there lava here? That heat shield would need to go somewhere.

Level 6:

More rock.. hmm. I don't mind reusing sharks.

Level 7:

Angler fish, please (has a light on its head)

Level 8:

Is it abandoned? It'd bug me if the advanced civilization always ended up extinct. Whatever, make a big gem of some sort I suppose. I really depends on what the "big" treasure should be.

Sunken ruins... I don't know what puzzles will go here, but the ruins should definitely be made with the puzzles in mind.

BTW! At the end of February, someone created what appears to be a very good convex hull plugin for Blender--the other one didn't end up in Blender's actual tool menu and was a bit buggy.

Check it out!

http://michelanders.blogspot.com/2012/02/3d-convex-hull-in-python-blender.html

Weekly Report (March 2nd)

This midterm week was "fun," but the old convex hull script converted. The majority of the week was used tweaking for either collision or movement errors.

My current concern is the player's moving between zones effectively--the current system does not allow the player to move to Free Move Zones lower on the list.

I have identified the cause--it has to do with the FMZs intersecting, and getFMZ() returning the first zone it finds on the list:

• When the player tries to exit the portal, getFMZ() gets the first zone on the array list that the player is within.
• Then, the player collides with the incorrect FMZ.

I have an idea of how to fix it:

• The portals currently store a direction that specifies which way points to a destination zone
• if we compare the direction that the player is moving to that stored direction, then we can get which of the connected zones that they probably are moving to
• all we'd have to do is make sure the player is really within the zone with the FMZ's isPointWithin() function.

I can code this in an instant (got it laid out in my head!), but I don't have the latest SVN--and the EKU firewall is a problem for being off campus.

@Shea and Matthew: if you have the latest version, I think I only need to change the Character.cs file (emphasis on "I think").

Hey, here's my attempt to upgrade the Blender 2.4 convex hull script to Blender 2.6x

http://www.pasteall.org/29606/python

The past week and this week I have working on getting my program to be able to load and create multiple vector fields dynamically. I am also working on adding different properties to these vector fields so that forces can be applied to different objects and a direction property will also be applied to the velocity of different objects. I am trying to find other properties that could be useful to better represent an underwater simulation.

Andrew Harmon - Weekly Report #4

This week I've been working on attempting to combine textures with lighting. The first step is to send the texture coordinates from the model into the shader. Within the shader the vertex input will be the color, position, and world normal. The vertex output will be the same. They should look like this...

struct VertexShaderOutput
{
float4 Position : POSITION;
float3 WorldPosition : TEXCOORD0;
float3 worldNormal : TEXCOORD1;
float4 Color : COLOR0;
};

struct PixelShaderInput
{
float4 Color: COLOR0;
float3 Position: TEXCOORD0;
float3 worldNormal : TEXCOORD1;
};

In the pixel shader the texture coordinates will be added to the lighting to create the look of a texture in a naturally lit environment. Here's a link that I found helpful. http://digitseven.com/texturing.aspx

Weekly Report (Feb 25)

This week had a few issues come up while combining projects. Making the FMZ's convex in Maya is harder than it looks. However, I did find an "ancient" python script for Blender 2.4 that creates a convex hull--and on a test, it worked! I'll look over it to make an updated script for Blender 2.6x, but I'll need a little time--especially given some other endeavors that require attention.

Also, something is wrong with the NPCs' motion paths. Occasionally, they just wander out into space.

-Jason

If anyone is looking for the Convex Hull Script, I found it within this forum:

http://blenderartists.org/forum/showthread.php?65972-Espresso-v1.1-(full-source)&p=610630

Weekly Report (Feb 24)

I've been combining my two projects together, so that magnetic surfaces and block pushing can both be used. However, I have been having issues with getting the block pushing to work right. For some reason, the camera won't interpolate correctly and then the game soft-locks. To try and fix this issue, I've basically doubled all of my variables that have to do with collision - one set for the walls, and the other set for the blocks. I'm getting closer, but there are still problems.

Weekly Report (Feb 18)

Hey, Jason here.

This week was uneventful--although I was trying to resolve an issue with the NPC's facing and the Bezier paths, it did not work out.

I uploaded last week's more stable version to our new svn server.

Here is the math I used to make the middle Bezier control point formula--in case someone sees what I missed.

The goal is to complete:

B(t) = (1-t)(1-t)a + t(1-t)b + t*t*c

given that I know B'(t) for t=1 and t=0, a, and c.

I was using the derivative to solve for b because t=0 should be startT and t=1 should be endT:

B'(t) = 2(1-t)(b-a) + 2t(c-b)

startT = 2(b-a)

=> 0 = 2(b-a) - startT

endT = 2(c-b)

=> 0 = 2(c-b) - endT

2(b-a) - startT = 2(c-b) - endT

startT - endT = -2b+2a +2c-2b

startT - endT = 2(a + c) - 4b

4b = 2(a + c) - startT + endT

b = (2(a + c) - startT + endT)/4

I could have made an error on campus--I'll check on it Monday.

Andrew Harmon - Weekly Report #3

One interesting thing that I did recently that someone could possibly find useful was creating a fog affect in an underwater ocean scene. The basic concept is that the further an object is from the camera, the more the color changes from one to another. So in a way the scene becomes kind of like a 3D gradient.

The changes that need to be made will take place in the fragment or pixel shader. First you must initialize your fog color, as well as the fog start distance (where does the change of color begin to take place in relation to your camera) and also the fog end distance (at what point is there no longer a change in color based on distance).

The remaining bit of code looks like this.

float diffuseIntensity = saturate( dot(-lightDirection, input.WorldNormal));   
float4 diffuseColor = lightColor * diffuseIntensity;  
float4 specularIntensity = specularColor *  pow( saturate(dot(input.refractVector, input.directionToCamera)), 1.0);   
float l = saturate((input.Position.z - FogStart) / (FogEnd - FogStart));

return float4(lerp(input.Color,FogColor, l));

input.Position in this case is the camera position. You will use this to figure out how far the pixel is from your camera. And based on the you will use the lerp function to effect the color based on "l". (that is an l as in lion, not the number 1)

You will then return color based on the calculation.

Weekly Report

This past week I have worked on getting my code to work to get the water simulation to work. I have used that content processor to load the models ( cube and cylinder).  In the update function I define a zone for each shape with its vertices. To decide how the cylinder's velocity is affected, I check how many vertices of the cylinder are in the cube zone and multiply the percentage by a velocity change. So when the cylinder is within the cube its velocity changes. I have added another cube to get the cylinder going back and forth between the two cubes.

Weekly Report (Feb 11)

Jason here,

This week, I discovered and resolved issues with the nav graph generation method. The biggest problem was occurring when nodes that should have been navigable were not usable; the graph generator thought they had already been traversed.

Also, NPCs can move along Bezier curves, but it could use some tweaking as far as their ability to turn around goes: as NPCs move along the path, their direction is not completely related to their movement direction--this was done in order to create a smoother transition between portals: it appears more continuous in that case, but looks terrible when they need to turn around.

I am not sure what next week's plans are--if the group will be combining the projects, then that will be the focus, but if not, then I will direct my attention to implementing the NPCs' various states and movement behaviors--so far, these states include things like: retreating, attacking, evading, moveToLocation, following, wandering, and idling.

I had been thinking about these behaviors, and I believe that it would be interesting if the NPCs had their own hierarchy in which they may hunt each other as well as the player.

This applies mainly to Myriem, Matthew, and me: make sure the objects that you create code for can be loaded dynamically from an Autodesk fbx file, a text file, or some other medium that is not compiled into the game; I'll be choosing fbx format mainly because model editors can function as our level editors.

I already proved the feasibility of the concept with the nav graphs, and it makes it easier to make levels in the long run.

I can give advice on how certain elements could be loaded if you all want me to.

Later

Weekly Post 2

This past week decided on what bounding volume to use to represent represent the sub and sea creatures.  I decided on multiple bounding spheres.  I used Maya to place spheres that approximately fit to a shark model.

Then XNA fits bounding spheres to each mesh. I do collision detection on the bounding sphere for the shark mesh first and if a collision occurs then I check for a collision with the smaller, more accurate spheres.

Andrew Harmon - Update #2

A simple solution I found for creating a caustic effect on objects is by first creating a wave function like this one.

float wave(float x,float y,float timer)

{
  float z = 0.0f;
  float octaves = 5;
  float factor = 1.0f;
  float d = sqrt(x*x+y*y);

 do {
     z -= factor* cos(timer*0.001*speed+(1.0f/factor)*x*y*wavesize) *
         0.3*sin(timer*0.001*speed+(1.0f/factor)*x*y*wavesize) * 0.8*sin(timer*0.001*speed+       (1.0f/factor)*x*y*wavesize);
 factor = factor/2;

octaves--;

} while (octaves > 0);

   return 2*amplitude*d*z;

}

This function will update be used to change the normal of triangles made up by the vertices in your scene. The triangle normal will be multiplied by the world normal, and then the world normal will be used to adjust the reflection and refraction vectors These values will be used to ultimately change the diffuse color of the object, and the specular intensity. . Here’s an example of how I did it.

float4 worldPosition =  mul(float4(position, 1.0), world);

float3 reflectionVector = normalize(reflect(-lightDirection , worldNormal));

float3 directionToCamera = normalize(cameraPosition - worldPosition);float3 refractVector = normalize(refract(-lightDirection, reflectionVector, 0.333));

float diffuseIntensity = saturate( dot(-lightDirection, worldNormal));

float4 diffuseColor = lightColor * diffuseIntensity;

float4 specularIntensity = specularColor *  pow( saturate(dot(refractVector, directionToCamera)), 1.0);

Weekly Report (Feb 4)

Last night, I finished the recursive algorithm that generates the next hop information for each Free Move Zone (FMZ), destination, and portal. It loads an Autodesk fbx environment using the content processor, and, based on some mesh naming conventions, it automatically generates the FMZs and portals within XNA. I had been fighting with simple issues--like accidentally resetting the center point of my portals--but now it is good to go. Here's the reasoning behind next hop forwarding:

• Each FMZ (f) has a set of portals (p) that lead to other FMZ's
• I go through every other FMZ (g) and I use A* to find the shortest path to each zone in g after going through each of the portals in p.
• If you cannot navigate to a zone from a portal in p, it is assigned a distance of -1, and otherwise, it is assigned the distance that is measured between portals until you reach the zone (adjacent zones in f and g have distance 0 because they share a portal).
• Using this information, I can determine the fastest route to a point within a destination FMZ given a point that is within the starting FMZ.

Later today--to make doubly sure I don't get behind--I'll be making some simple NPCs navigate between areas--to start off, they will only move in straight lines between portals to reach the center point of some zone or another.

I'll post some code samples for both topics after I make sure the NPCs navigate well.

Signing off,

Jason

2/3/12 Weekly Post

This week I have worked on refining my engine for block pushing. It's finished now, and you can grab the code here. The camera now interpolates to face the direction of the block you are going to push. Also, it intelligently picks which block to push based on which one you are facing, and if you are facing it at a shallow enough angle.

There is a simple HUD as well that shows the player's coordinates, as well as if you meet the requirements for pushing a block and if so, the block's coordinates as well.

Next week I will begin developing new mechanics that are equipment based, to get us closer to developing actual puzzle sections of the game.

-Matthew

Last Week's Weekly Report

I have been working on predictive triangle collision. I created a ray starting at the current position and pointing in the direction of movement. Then I tested for collision between that ray and all the terrain triangles. I borrowed from this example for getting the triangles from the fbx model and ray-triangle collision. Then, if a collision occurred, I checked if the collision occurred within the distance moved.

Weekly Report - Water Simulation

This past week I looked into ways to simulate an underwater simulation, I didn't find many resources. But I found out that a way to simulate the underwater effect is by using the post-processing technique which is applying an effect or a combination of effetcs to a certain scene. This post process efffect can be considered as a filter the scene is going through.This scene is rendered into a texture, and that texture is used to render the scene, when rendering the post process shader is applied. So to simulate this underwater effect scene I am going to need to implement the post process shader that will need a pixel shader and to make the shader dymanic a timer is implemented.
Please let me know if you have any suggestions for the implementation of this effect, or if you think that this will be inificient.

Report for Last Week

Last week I worked on getting basic mechanics for pushing blocks around, and getting familiar with how something like that could work. I made it possible that the player can push more than one block at a time, or only one if that's what you wanted.

I also worked with the camera in these situations trying to get it to feel natural and more like games that we all know and love. Quaternion.Slerp() does a very good job of this, it's just a matter of tweaking variables to get it to feel natural.

I uploaded my project here (EDIT: This link is now dead, you can grab the updated code from this post) in case anyone wants to see exactly what I've done and how it works. Suggestions are welcome too, if you feel something I'm doing is inefficient or could be done in a simpler way.

Weekly Report - Andrew Harmon

So this week I’ve been looking into the best way to create an underwater effect that captures the look of light shining through the sea and lighting the ocean floor.

After doing much research and investigation I found that there are many ways to create the effect of caustics. Some methods are much easier to implement as others, and as is often the case, the easier it Is to implement the less realistic it will likely look.

The easiest way to create an effect is by using a caustic generator like this one. http://www.dualheights.se/caustics/. This program can be used to create a short animation that can be reproduced randomly on the ocean floor. However, this method would likely result in a floor that appears too repetitive, and it could be very easy to realize that the same animated texture is being used over and over.

In order to create a truly realistic effect you would have to actually create an effect that simulates the realistic movement of an ocean surface. You would then have to determine the intensity and direction of the sunlight. Then using refraction and reflection equations you would have to trace each photon of light and determine the effect that each equation would have with the water it intersects with. The rays would then be traced to the ocean floor, and then based on the murkiness and depth of the water, a certain amount of light would be reflected on the ocean bottom.

Now that would be the most extreme approach, but there are other methods that are a little easier to implement with similar results. This poster goes into a little more depth on some different approaches. http://www.3dbuzz.com/vbforum/showthread.php?186376-XNA-underwater-caustics&daysprune=-1#post1536229

The method I have chosen to implement will use a directional light, which will intersect with some imaginary wave functions, based on where the rays hit the normal of the vertices of this wave, the light will be sent in different directions, or will not be calculated. This will created a “spotty” effect on the ocean floor, creating a similar look to an ocean floor in shallow waters.

This is only one aspect to making an ocean look. There is also the aspect of visibility. Based on how “foggy” the water is, and the color of the water is, you may be able to see only a hundred feet in front of you, or you may be able to see hundreds of yards in front of you. But one thing that is certain is that objects will appear less distinct the further they are from the viewer.

Another aspect to some parts of a sea is the light rays that pass through the water, giving it a slight, but constant change in color.

Also for some finishing touches, some floating particles, and maybe some shadows from the sea creatures can be added to the ocean floor can be added to the scene.

Here’s a clip from Finding Nemo where you can see all of these aspects working together. You have the caustics, the fog, light rays, particles, and shadows.

It’s not an easy task to create realistic looking water, but these are some ways that it can be done.

Weekly report (Jan 27)

Jason here,

This week I determined how the NPCs' movement between static areas will occur:

• There are predefined, convex hulls that represent more complex areas that are called Free Move Zones (FMZs).
• These zones are connected by portals. Portals designate where it is safe to pass from one FMZ to another.
• The portals will use Next Hop Forwarding to determine the fastest routes to a destination. These routes will be pre-generated using the A* algorithm.

So far, I have the basic environment processor finished; it reads an Autodesk .fbx file and loads the FMZs and portals, and it also links the portals and FMZs together.

In addition, I have developed an algorithm to test if a point is within a convex hull. Tell me if I'm wrong! I made it up in a hurry, but the principles made sense at a glance--I'll probably get to test and tweak it before next week is finished. I hope it seems just as clever by then : )

// point is the Vector3 being tested

// centerPoints[] is the array that contains the center point for each face in world space

// dirs[] is the array of normals for each of the faces

// this assumes that faces point outward

for (int i = 0; i < currentFaceCount; i++)

{

// the outward direction (if it is within the convex hull, anyway)

Vector3 dir = centerPoints[i] - point;

dir.Normalize();

// recalling linear algebra, this measures the angle between two vectors

double angle = Math.Acos(Vector3.Dot(dir, dirs[i])/(dirs[i].Length() * dir.Length()));

if (angle < 0 || angle > Math.PI) // is the opposite direction

{

// point is not under the plane, so it is not within the convex hull

return false;

}

}

// point was "under" the plane for every face, so it is within the convex hull

return true;

Interactions

The subs weaponry and other equipment will attach to the outside of the sub. When the sub hits something, if the equipment gets hit it will take damage and eventually become unusable until you repair it. Running into walls or rocks cause a relatively small amount of damage. When the sub runs into an enemy it do damage to both the sub and the enemy. For weak enemies it do more damage to the enemy, for strong ones it will do more to the sub. Sub weapons will do more damage to enemies than hitting them. If an enemy hits the diver it will do a lot more damage and not hurt the enemy. The strongest enemy will kill the diver with one hit.

The game could be kind of like...

I could see something like this working well for the submarine view. Obviously the environment would be underwater. What do you all think?

 

 And then once the person gets out of the submarine the camera would follow the person instead of the submarine.

This second video is a little different in that it allows you to view all sides of the player. I could see this also being a useful technique.

Environments

Level 1 – Sandy Floor

Environment – A lot of sand, with a few rocks sprinkled throughout the landscape. Many of the items are clearly visible making them easy to collect.

This level has very few enemies, with a fair amount of treasure hidden in the sand. Some clues may also be found here that will help in future levels, but the main purpose of the level is to familiarize the player with the controls and how the game works. 

Level 2 – Greenery

Environment – A lot of grass and small bushes, with some large rocks scattered across the seascape.

A few more predators are introduced, as well as some clues found between rocks that are hidden between lush foliage on the ocean floor.

Level 3 - Corral Reef

Environment – Obviously there would be quite a bit of coral, as well as small caves, and exotic plant life.

This level has a lot of treasures, but they are hard to find, because they could be so many places. Also coral reefs are filled with sharks, eels, and other dangerous creatures.

Level 4 – Abandoned Ship

Environment - A small rocky valley where an old ship is found. Most of the level would take place inside of the ship.

The abandoned ship may not have many little treasures, but they say there is one big one hidden inside of it somewhere. But not just a treasure; this ship could hold a secret that must be uncovered in order to move further into deeper waters.

Level 5 – Underwater Mountains (rocky)

Environment – This level takes place in what appears to be an underground mountain pass. There are several caves and caverns to explore.

As you move into deeper waters you will have needed to collect advanced equipment in order to survive. This place is full of magma, sharks, and other mysterious creatures rarely seen by human eyes.

Level 6 – Moderately deep trench

Environment – Similar to the previous level, only with steeper sides to the cliffs around the trench, and a flatter ocean floor. It is also considerably darker.

Few venture into the trenches, but this is one you must explore, because hidden in the caves of these trenches are some very important pieces of information. You will need to use your problem solving skills in order to solve the puzzles and gain valuable information needed to completely the quest. (And some treasure of course)

Level 7 – Deep Trench

Environment – Very dark, with little vegetation.

Unlike the previous level where there was a little bit of light, this deep trench is completely dark, so you must rely on the lighting around you, and the light provided by the sea creatures in order to see your surroundings. The last piece of the puzzle is found here. You now know where to go to find the much coveted Atlantean treasure. 

Level 8 – Atlantis Ruins

Environment – I mixture of a few plants, but mostly sand and rocks. There are several ancient ruins that are crumbling.

This level is by far the most difficult. There are many dangers, and you must use nearly all of the equipment you have purchased in order to complete the final level and obtain the crystal. The most formidable creatures, ones never seen by modern civilization are guarding the treasure, and will not give it up easily. 

I looked at a map of the ocean to see where some plausible locations for these different environments would be, and from that I made this map.