Good prizes as well.

Dream Build Play

St. Mary’s College is fielding two teams for Microsoft’s Dream Build Play contest. I’m part of one, we’re working on ideas now. Hopefully we get started soon, we only have approximately two months left. Should be a blast if we can dedicate some time and effort to a good game building on experience from last year.

Thesis

I’ve a final thesis to do. I want to build robots. This is not entirely physics as my adviser will probably point out, but I am a joint major. So, at the suggestion of a partner, we’re going to play with genetic algorithms and robots.

First Stages:

We need a robot platform, and we’re strapped for cash. I’m going to be in charge of building something cost effective that will allow us to run simulations from a host. Let’s look at some candidates for parts for a platform to test the feasibility of our idea:

• (1) PICAXE-08M Microcontroller - the brains of the little guys. 128 bytes to work with. 8 pins. This could get hairy!
• (1) L293D Driver. Used for controlling motors. Actually, we might be going with a project board for the picaxe which would give us 4 digital on/offs and 2 reversible power outputs without much headache. Enough to turn two servos and collect a little input from the environment.
• (1) 5V Voltage Regulator. We don’t want any blue smoke.
• (2) Microswitches to collect input.
• (1) 9V Battery.
• (2) GM10 Motor Kits.  They have to move somehow.

All of these parts thrown together should make a fairly basic robot. If we add a wireless serial controller, then we’ve a mobile platform which we can control from a host.

Where’s my credit card? I’ll be using it at Octopart, that’s for sure!

Steve

A large part of part of scientific research involves the principles of optical and atomic physics through laser-driven saturated absorption spectroscopy. In this experiment a single laser is split to provide both a pump and probe beam to examine the absorption spectra of a vapor cell containing primarily rubidium85 and rubidium87 as shown:

The How.

Initially, one must check for fluorescence within the vapor cell to ensure that the laser intensity is tuned properly. Very precise control of the laser is provided by frequency and temperature (wavelength) locking circuits. Once fluorescence is achieved adjustments are made to the frequency of the laser (adjusting the voltage to the laser’s PZT) to “scan” over the spectra lines of the ground and excited states of rubidium. These lines are observed on a digital oscilloscope. One small change is to be noted: the photodiode in this experiment had two active regions and a subtraction circuit attached to it. This allows for the account of Doppler shifts within the vapor cell while scanning to provide clearer spectra lines.

Once several lines were observed, the best observable spectra lines are recorded. See below (Standard Transition Level Schema) for expected states to be visible in the experiment:

Next, the vapor cell is switched out with another wrapped in coils of wire attached to a power supply in order to observe the effects of a magnetic field generated by the Zeeman shifter on the vapor cell. Once the Zeeman shifter is powered, another absorption line is recorded and saved once again for comparison to the preliminary lines where a splitting of the lines should be observed. See below for a visual representation (Zeeman Level Schema) of the splitting expected.

The Numbers.

Rb85 5P_3/2 Spectrum Lines:

Table 1: No Effect, Rb85 5P_3/2

Zeeman Effect Spacing

The Outcome.

The exercise of this experiment is particularly useful in determining the proper operating frequencies of a laser allowing an individual to create a magneto optical trap or MOT. Principally, one should be able to find the frequencies at which it is possible to slow rubidium atoms both when under the influence of the Zeeman effect and otherwise. Although after considerable trial and error in the short lab window given, we were able to properly align the optical setup with the diode to achieve both a pump and probe beam providing fluorescence, it was difficult initially to locate the spectra lines of the rubidium in the vapor cell. After finally getting clean lines without the Zeeman effect, an average frequency spread was calculated for the Rb85 5P_3/2 transition lines to be approximately 11 GHz with an average spreading of 5.6 GHz/Volt. These findings seem to be valid. However, once the effect was introduced severe noise was clearly visible in the signal on the oscilloscope most likely from building vibration and potentially interference picked up through the effect’s wires. In order to combat this issue, the digital oscilloscope’s snapshot feature was used to prevent movement of the lines while recording data. This may have negatively impacted the Zeeman effect data even though multiple snapshots were taken, as the spectrum was constantly moving on the oscilloscope.

Thus, the first half of the experiment was useful in observing spectra lines. Noise and incorrect data in the second part of the experiment involving the effect resulting in 40% error is unsatisfactory to make any conclusions about the effects of the Zeeman effect on splitting spectra lines. However, the splitting is indeed visible. If the experiment were to be repeated, greater care eliminating noise and alignment should be taken, as well as increased resolution on the oscilloscope in order to achieve a better comprehension of the Zeeman effect. It should be noted that this research was conducted as an undergraduate experiment and the results are not to be considered valid as the experiment was repeated later with greater precision and verification. If there is any incorrect information presented please feel free to send me an e-mail, I’d appreciate it!

It was a long road, but in roughly three months my partners and I went from absolutely no engine to a complete and playable game which we presented in front of roughly a hundred people.

Is it fun?

We hope so! The crowd, Microsoft MVP’s and our professors seemed to enjoy it. Two players move through three levels, taking on various aliens and bosses until they get to the end of the level. The interesting dynamic is that one of the players is strictly “hand-to-hand” except for a “gravity gun” which the player may use to draw enemies towards themselves. This really becomes important when facing the bosses of the levels as one player has to quarantine and control the enemy, while the other shoots it into oblivion. The premise of all this madness is that an alien race seeded the Earth a few million years ago with life. Every so often they come back to “harvest” the organisms that have developed for energy. What do you think happened to the dinosaurs?

What did you do?

I worked primarily on base engine code. Physics, controls, level construction and cleanup, entity handling, etc. The beauty of my work was that a lot of the difficulties in game design were already taken care of in the XNA and TorqueX frameworks we used. It was just a matter of implementing the respective frameworks on top of each other properly. My favorite part was coding in some basic Newtonian mechanics. OK-More like Aristotle’s mechanics, but still fun. Here’s an excerpt of the code used to imply an impulse to the player when firing a weapon:

Vector2 impulse = new Vector2();
impulse.X = (float)Math.Sin((double)MathHelper.ToRadians(-_player.Rotation + 180.0f)) * -_projectileKickback;
impulse.Y = (float)Math.Cos((double)MathHelper.ToRadians(_player.Rotation - 180.0f)) * -_projectileKickback;
_player.Physics.ApplyImpulse(impulse);

My other team members put a lot of effort into this project. One of them focused
primarily on the user interface, artificial intelligence, and coding the weapons. The other did a fantastic job of creating all the sprites and sounds for our game. His work really added a whole dimension to the project by giving it a polished look and nice animations. Not only that, but his bosses looked menacing!

I also focused on the “Level Editor” which was coded in Delphi 2007. It helped us streamline designing the levels near the finalization process of the game. Not very elegant at all, as it simply generated a text file with entities which the game engine parsed. Also, using the editor, you can only specify rectangular bodies for defining the collision edges of a level.

Reprise

That’s it. If you want more information head over to The Second Coming on GoogleCode. There you can download the source and binaries of the level editor and game itself. There’s lots of work to be done to complete the game and squash some bugs. Overall it turned out to be a success. I hope this will be one article in a series about game development at the student level and the details of The Second Coming. Enjoy.