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