Fluid simulation, Atari 2600 programming

Fluid simulation update

I added more features to my fluid simulation. Follow the links to see movies:

• Fast approximate far-field interactions
  
• Semi-lagrangian simulation for comparison
  
• Brute-force O(N^2) vorton simulation for comparison
  
• Other visualization modes (still preliminary)
  
• Objects affect the fluid
  

I also submitted an abstract to GDC for 2008.

Atari 2600 Programming

I collect Atari games, consoles, controllers and other Atari-branded stuff from the 1970's and 1980's. I'm also beginning to program the 2600. Its CPU is a 6507 which has the same instruction set as the 6502 but has fewer address pins. Many computers from that era used the 6502 including other Atari consoles and computers (5200, 7800, 400, 800, etc.), Commodore computers and the original Nintendo (NES). It's the first CPU for which I learned assembly programming. The Atari retro development community is quite active and even now, around 30 years following its release, people continue to pioneer new ways to get more out of that console, e.g. higher image resolution. Each year at the Classic Gaming Expo people release several new games for the Atari 2600, and they usually sell out immediately.

I recently obtained a collection of EPROMs (which currently have Atari games burned onto them) and 2 modified Atari 2600 cartridges with ZIF sockets that fit these EPROMs. I put the chips into a conductive plastic container I got from Skycraft Surplus for $2. This gives the appearance I'm engaging in industrial espionage.

Programming is where it's at!

Wow, are we really starting our 7th week? It seems like we've just begun, yet we've already done so much. We've finished our first two rounds of prototypes, and I was very pleased with the work both of my teams did. Those were written in Flash and Actionscript, and several very interesting games came out of those two-week rounds. Now we are starting on our 3D prototypes using Panda and Pyton, and again we have just 2 weeks to create a game - this time focusing on story. Of course, that's not all we are doing. The programmers are working on some very involved C programs (after doing a few tough assembly programs - whew!), the artists are all designing/texturing/animating character models in Maya, and the producers are, well, producing. I can pick on the producers because I originally came into the program as a producer (a technical producer as you may hear them called). But after sitting in on the programming classes and realizing I didn't have a good answer for "What does a producer do?", I decided to switch tracks. And don't let "Sir Charles" (or Chuck as we like to call him) fool you. The job of a producer is not that sexy. The real sexy jobs are held by programmers. Don't believe me? Just take a gander at Dr. Gourlay's blog on "Fluid-like Simulation". Very Sexy!

But we already knew that. What I have learned is that you really have to prioritize here. In undergrad, prioritizing just meant figuring out what you could put off, and what you couldn't. But here, you are working with teams that depend on you. And frequently you are working on different teams at the same time. Should I work on my programming assignment right now? What about my prototype team that needs me to write code for our game? And how's my development plan team coming along? Of course, the other team members on each team are also juggling assignments and teams, so getting everyone to do what you need when you need it means we all have to do a little "producing" of our own.

Fluid-like simulation (preliminary)

Existing fluid simulations based on solving the Navier-Stokes equations or its derivatives are slow algorithms. For games, we need something faster, perhaps at the cost of quantitative realism.

I aim to invent a simulation algorithm to satisfy these requirements:

• Fast; must run in real-time
• Scalable; i.e. O(N) or better
• Qualitatively similar to real fluids
• Simple to implement and modify
• 3D
• Interacts with other entities
• Multiple immiscible fluids (e.g. water and air, including surface rendering)
• Combustion

I will use an ad-hoc simulation using something akin to point vortices that interact with their nearest neighbors .

You can get more info from my website: http://www.fiea.ucf.edu/~mgourlay/Fluid/

Earlier this week I managed to create some preliminary results of a fluid-like simulation of something like a vortex ring moving through something like a fluid, including these features:

• Nearest neighbor tracking
• Particle rendering
• Particle interaction

These simulations share in common with real fluids vortex self-advection due to nearest neighbors and vortex diffusion. Mathematically these properties differ from those of real fluids but qualitatively this simulation has those properties. As you can see from the simulations, the vortex ring does indeed propagate as you would expect from such a ring in a real fluid. The aggregate speed is probably wrong though.

These preliminary simulations lack a number of features present in actual fluid dynamics, including vortex stretching and tilting (important for cascading from laminar to turbulent flow), no-slip boundary conditions (necessary for generation of vorticity such as generating wakes and lift) and potential (i.e. irrotational) flow (necessary for bulk fluid motions such as occurs in shear flow far from the shear layer itself). The simulation code currently includes propagating long-range interactions. I intend to add the other features soon.

You can find some movies and more details here:

http://www.fiea.ucf.edu/~mgourlay/Fluid/2007sep17/

Games, Dames, and Lames: Producers Be Cool

The original blog that I wrote for this posting was just about the dames of video games. The fellas and I were talking about the lovely ladies involved with the video game world, so I decided to write about them. Then, I began to reflect on my experience at FIEA. So, my original blog went out the door. For an entry more meaningful for future designers.

FIEA's Rapid Prototyping curriculum is very aggressive and fast-paced. If you blink, then you would have missed a load of information. We actually gain knowledge about rapid prototyping through instruction, a plethora of resources, freedom to design anything, and a nonstop stream of prototyping opportunities. Feeling slight pressure to produce the best product, I learned sacrifice is a virtue worth developing and cultivating. My first sacrifice was sleep. I've never been to fond of sleep, so it was a simple decision to make. I'll sleep when I'm dead.

At 3:AM, I am up reading as much information as possible to strengthen my ability to obliterate production obstacles. As a producer, I need to be able to create an efficient system to design the best game possible within specified time parameters. Moreover, my first obligation is to make sure my team is completely satisfied and comfortable with the game idea. The only way to establish that comfort is to constantly ask for feedback about the idea and incorporate the ideas of the team into the game.

I've learned that open over-communication is necessary in making your team feel comfortable. I have to make sure that my programmer and artist are capable and able to deliver their pieces of the game design puzzle on time. I have to make sure that the artist understands the programmer's capabilities and the programmer understands the artist's capabilities. Then, I convince them to work in tandem on constructing the best game possible. Furthermore, I have to make sure neither the programmer nor the artist gets burned-out or broken in the game making process.

Many people think being a producer is a hack job. But, it is quite stressful when you realize that your team must be satisfied and comfortable. A producer must be concerned with the personal lives of his team because personal issues do spill into the workplace, and can adversely affect the team's morale. A producer has to create and maintain a stable working environment. In a nutshell, the producer's job overall is to make sure that the other team members do not worry about anything except their task at hand. Any distractions or disruptions can halt momentum and destroy morale. Once morale is lost, then the battle to complete a game is uphill.

On our last rapid prototyping assignment, I watched some teams lose momentum and their morale plummet into chaos and desperation. Many of us, noob producers, are stuck in our ideas and never get around to actually designing the game until it is too late. A producer needs to be ten steps ahead of her or his team in order to be victorious in their game design. The worst situations snowball when a team loses momentum due to a producers inability to solve a problem in a timely manner. All producers should learn how to foresee any and all possible problems. In reality, I know it is impossible to foresee all possible problems that rise up in rapid prototyping, but a producer should be prepared for any problem- personal or professional. This ability to problem manage is called "cool." I've seen producers lose their "cool" with their team. It isn't a pretty sight. The team usually loses respect for him or her, thus causing the game to suffer. Believe me, that loss of confidence and loss of trust shows in the final product.

Note to all producers: Producers maintain your cool. It is not the job of the programmers and artists to worry about the overall design. That worry falls on you. I watched as producers get so caught up in their own tasks that they did not answer their team members' problems. Programmers and artists do not appreciate a self-absorbed producer. Your programmers and artists' gaming issues always outweigh your own, unless your issues have a negative effect on their work. A producer needs to show his team how much he cares about them before he or she unleashes unreasonable demands on them. Your teams efforts must be appreciated and respected. Producers are the coach and the cheerleaders for their teams. If you subscribe to keeping high morale and maintaining your cool, you will produce a good product.

As I step off my soapbox and face the calm before the storm, I wish all aspiring producers the best of luck in their productions endeavors. Remember, don't get hung up on your production hardships, we all feel your pain. Be cool and overcome.