So for this week, there was a lot of progress made on the code side. Jared managed to get a lot of the code simplified and modular so they can be imported into flash with ease. I (Nick) got all the collada characters as well as some items made correctly and into the level. My next item is to figure out the collision detection which should be pretty difficult, based on some early research. Todd continued with concepting for the new website which will feature the game itself after its completion. We met this week on Thursday and went over all the items that we’re going to talk about for the presentation tomorrow (Tuesday). We originally wanted to have the cube with the IR goggles up for use for the presentation, however, since the presentation got pushed (or rather pulled) forward, we’ll just have to settle for a video of the system working. Jervo also got the wireless wii sensor bars so that will be great to use for testing purposes in the upcoming weeks. This term overall has been fantastic as far as development and we’re looking forward to continuing next term.

Week 8 Hours

This week, I got all the characters imported and working correctly. Each DAE is only about 100 Kb so they’re pretty small, even with animations. I’m still working on making the down button enable them to turn around and walk in the oppisite direction. Right now, if you hold down they basically seizure a bit until you let go.

I also created a castle, cactus, and tree inside maya then exported them as collada files and brought them into flash. I was surpised to find that they were about half the size of the character animations. I really thought they would be much smaller, like a fourth of the size. I guess the animations on the character collada have less affect on size than I previously thought.

Here is the new cube example that I created.

Example

Finally, I started doing research on the collision tests. It looks like this may be fairly difficult. I found several options. Right now, sphere collisions looks like the most feasible but there are some nice collision tests available with the WOW physics engine that is capable of working with papervision. This is really the last major functionality item that I have to get working before the game level can actually start to be built.

FINALLY!
I finally got this working the way I wanted it tonight. It was such a simple solution I have no idea why it took me so long to get it…
You can now move in and out and the cube will scale appropriately. You can also go out of frame and the cube will no longer jump back to the default settings…it will ease back into frame once you move back.

The way I calculate Z depth is by taking the two IR locations on the X-axis and getting the difference. Basically triangulating them…so when the glasses are closer to the WiiMote the distance is physically greater apart, giving me a larger number, and when I was far away it was a smaller one. This all made sense except I couldn’t get a formula that worked well to actually make the camera move the way I wanted it to.
No matter what I did larger numbers always ment closer, but adding lager numbers onto the camera distance only made it get further away. And I couldnt just subtract it because that would cause the camera to constantly be moving away…it was a chore.
In the end I found that simply by choosing an absolute value for the camera’s distance I could simply move it closer and further. It turns out I was over thinking the whole process…

Check out the formula for movement in the Y direction:

camera.y -= (camera.y-(rY*0.5-w1Y)/(rY*0.5)*1200)*0.2;

And the Z:

camera.z = -2000 + (w1Z*2);

Much simpler…no? The -2000 will end up being dynamic based off some screen resolution tests. I’m running 1440×900, so maybe it will just be ResX+500 or something…I’ll figure that out later.

Anyway, since like always you can’t really run any of the examples I post up, I figured I make a video clip of it. Take this, and add 1 million more awesome points to it and that is how it looks in real life.

I made a little video of our Cube Walkers example that Deimler just posted up.  The music couldn’t be any more appropriate.

UPDATE - I fixed a few bugs. I now have the boundaries working. I also made it so that the user cannot switch to a different character if they are still holding down the “UP” button. Hurray!

Updated Characters

For this week’s progress, I managed to get the character into flash with animations! Very cool. I found a class file posted by some guy named Pablo (Pablo’s Code). He made a DAEMC class that allows simple manipulation of keyframes using the gotoAndPlay or gotoAndStop as well as a number other nifty little methods like setFrameLabel or addFrameScript. The gotoAndPlay/gotoAndStop function just like they do in flash normally, except you goto the frames of the DAE file animation. The addFrameScript and setFrameLabel allow you to label frames of the DAE file for easier manipulation. Using this class gave me the ability to allow the user to manipulate the character inside the 3D world using arrow keys.

I also made it so you can cycle through each character and move them individually by pressing the “SPACEBAR”. HOWEVER———-there are some bugs: yes, he gets stuck at the edge if you go to far, he will not walk back. Also, if you press space without lifting off the “up” button, the guy will sort of glide without walking. A final bug is that when you press down, the character will turn around a bunch, but he doesn’t walk in that direction. Hopefully he will soon. I’ll be working on these bugs for next week, I was just happy to be able to manipulate the animations inside the swf.

Cube and Character Example

For next week, I’m also going to work on getting the 3D models in. They will just be simple ones but make the box look a little less like just a box.

These are some of the main item blocks that will be scattered throughout the Fourmation levels.  The axe, bomb, shovel, and battery are needed to interact with other objects in the game.  There will be about 6 more special item blocks created this week.