Thinking Process

While working on the implementation of the game, various questions and challenges arise. The most important ones have to do with the jitter that is introduced due to the Kinect sensor. I have set thresholds for most of the movement and rotating monitoring but that diminishes the naturaleness of the motion. More specifically the problem arises when:

a) The remote player side walks, controlling the position of his window in his opponent's virtual world.

b) The remote player stretches or pulls his hands closer, controlling the size of the window in his opponent's virtual world.

c) The local player leans left or right to look into the still window of her opponent.

After making lots of tests I have manage to achieve a balance which I believe is acceptable both in terms of minimizing jitter, as well as effecting a relatively smooth motion (see video below).

Another issue that came up during "peeping" into your opponent's world is if the rotation is reset when the opponent is unfrozen. This is the default action at the moment, but I am not sure it is the optimal. The rotation currently freezes to where you left off when your opponent resumes motion and resets to its initial value when you freeze her again. However, it could potentially be more interesting to have all the bonuses scattered around each player, which would mean that you would have to freeze your opponent repeatedly and move around almost 360 degrees to collect them all! And just to add to the confusion, maybe while he's frozen he could -in some way- move the bonuses around to make your life more difficult while you were trying to grab them! I guess I have to reach this point and try out these ideas before committing to one or another.

These implementation, if they make it to the final version, bring another idea worth considering: would it be appropriate to include a top-down view of your opponent's world and an indication of the part you're currently looking? This would make you get a better understanding of where you are looking at, and could also function as a guide for the bonuses' locations. The way I envision such a map is depicted in the following image. Leaning your body and peeping through the window (as in the video above) would cause the highlighted, torch-like beam to rotate accordingly.

I was also thinking about shouting and how you could control the direction of the ball (i.e., the bullet). The angle of your body could be the obvious way to do this, but on second thought maybe such an option would deter the players from moving while trying to aim. Of course they would have to move in order to avoid enemy fire, but still another incentive would be to have the opponent directly opposite and fire at them. Again, this would have to be tested with actual players, but my intuition is that the more you involve the players in energetic motion, the more enjoyable the experience will be. The prospective of different fire power (maybe velocity and/or size) could be controlled from different body movements (e.g. hand-gesture shoots large but slow balls, while kicking shoots small and fast ones!)

Another concern has to do with the communication between the two players. My initial thought is network commands sent between the two machines, but I am not sure if this is the right decision. Another idea is having both players use the same machine with their windows projected on two displays (using a dual graphic card). Although this solution would relieve the application from having to handle network messages, it imposes another burden of having to drive two Kinects at the same time and propagate their sensor data to the application. Testing would be the decisive factor for this issue, too.