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