Head over to the DOWNLOADS page for all your Fourmation needs.

While the project is pretty much wrapped up I’ve been getting some emails requesting some basic headtracking code and examples for people looking to get started with their projects. This is one of the older and simplistic versions of the headtracking that eventually became fully implemented into the final Fourmation product. This relies heavily on the examples posted over at asb-labs (as you can see in the zip i even have their examples included for reference.)

In this early version I basically took the asb code and changed it around to move the camera in relation to the location of two IR points, rather than move a pointer on the screen. Check out the (very messy) WiiConnect and MainMenu classes to better understand how it works. While sloppy in this old demo, the same principles are what went behind the final product.

–EDIT–
Sorry, had the wrong zip file.
Anyway, check out some [BASIC HEADTRACKING]

You might notice that some of the more recent examples in previous posts are not working.  That’s because the files have server code in them and the server code (and location) has changed since posting.  Sorry.

I have just witnessed something I have never seen before while coding in AS3.  Two identical sets of code with the exception of one line, a simple trace statement, have different outputs.  The trace statement is actively affecting the compile.  I actually need the trace statement in the code, uncommented, for everything to work properly.  To see the differences between the versions, open one version in two separate tabs in your browser.  You will notice that the red (or blue) guy’s rotation is off.

test with trace statement | test without trace statement

and heres the code:

buddyArray[id].mesh.rotationZ = transformObj.rotationZ;

trace(”rotation Z: ” + buddyArray[id].mesh.rotationZ); // corrects rotation, but why!?

While scrambling around this morning trying to get walk cycles to work, I wrote some quick and dirty code in about 20 minutes.  I just had a chance to fix the code to make it as efficient as possible.  Witness the before and after by clicking “read more” below.  I finished the walk cycles by the way and I will be posting up the example as soon as I’m done cleaning up the code.

[Read more →]

especially when you can get it to work right.  As Chau said in the post below, we’ve had some difficulty getting ALL of the multiplayer to work.  We both managed to get connections working and the player sides updating when new users join the game, but the rest is going to be a struggle.  Almost every variable needs to be updated between the players, every wiimote button press, every character movement, every plane action….so there is going to be a lot of information flying around.  I’ve figured out the basics of sending info back and forth between the players, but for some reason it is only working right if you are Player 1 (the blue side).  The information that is being passed in my current build is the character boundary information, which lifts the adjacent planes around the plane you are standing on.  If you run two instances of my current build you will see, when you are playing as the blue side, the red planes will lift when you walk around with the red side character (but not vice versa).  I’m confident that I will figure all of this out pretty soon, partly because I have to, and partly because little by little things are starting to work right.

Run .swf | Download

This week me, kyle, and jared all met for a coding party to integrate this new server. However, the limitations to the coding party is that we all work in different conditions so it was not as successful. Also, the amount of problems we encountered deterred our progress.

So me and jared worked separately to try and solve this problem. The problem being that when a user connects he should be given his side. However, when another user connects, the first user’s game should update with the new user’s board as well. That way we can load anywhere between 2 and 4 players and not just 4 players.

So in a hilarious occurrence of serendipity i got mine to work and jared got his to work under 2 completely different sets of code.

Here’s my version. Enjoy.
click here.

This week, we introduced a major part of the multiplayer to the game code and managed to get most of the basic server connection code working.  We have been having some issues with the more complex information exchanges but are making progress.  Todd and Tom continued to work on the website, cleaning it up and tweaking some things.  For the week ahead we will continue to work on multiplayer code, and hope to have everything working (players seeing other players walking around and grabbing planes) by Sunday.

Week 16 Hours