The game “A Time to Kill” is a simple OpenGL first-person shooter where you run around and kill enemies. The enemies don’t fire back and run away when approached. The object of the game is to kill all the enemies before the time runs out. You are able to fire flame rockets and heavy missiles. Flame rockets fly faster and straighter, but heavy missiles have a larger impact area. The arrow keys move you around. The mouse will allow you to look around and aim, and the mouse buttons will fire your weapons.

DirectX provided all the sound and inputs controls for the game using its DirectSound and DirectInput modules, respectively. I replaced these as follows:

• For game input I used Windows’ built-in mouse and keyboard functionality. I rewrote much of the keyboard and mouse code in the parent window class file. It should be noted that I don’t think the controls are as robust as with DirectX, but this might have been different if I had tried using SDL’s input library.
• For sound I used SDL’s sound library called SDL MIXER. It provides a multi-channel sound engine I used to replicate all of the DirectSound functionality in the game. I added new sounds for weapon launching and explosions. In addition to sound effects, I added a looping “arcade-style” music file for some videogame ambiance. I wrote a new class AudioSystem from scratch to provide all the SDL MIXER functionality the game needed, including an interface for in game objects to play their own sounds.

NOTE: This game is very rough and simplistic, but it was designed to demonstrate the fundamentals of OpenGL programming and DirectX and SDL software architectures.

I used Java‘s small device application programming platform called J2ME (ME standing for Micro Edition). The J2ME framework is specially made to be lightweight and platform neutral for cellphone and small device development. These mobile apps are called midlets (as opposed to applets, servlets, and portlets), where MID comes from MIDP (Mobile Information Device Profile) which is the Java runtime environment for small devices.

WeatherMIDlet uses many standard objects and APIs. To navigate menus I used a CommandListener object. I used a ticker object for generating a scrolling banner that displays current temperatures for all stored zip codes. All the weather data is stored in a RecordStore object, and the weather server is re-queried periodically in order to keep the RecordStore current. I used a bean object to parse the string of raw uncategorized weather data from the weather service into its constituent parts. These are then stored by the main midlet which will output concatenated strings such as, “High of 67 today with a low of 49. Currently the skies are cloudy.” The internet weather web service I chose to use was wunderground.com.

This prototype is an e-commerce web store application with a working shopping cart that uses an MVC (model-view-controller) methodology. The front-end is coded in Java Server Pages (JSP) and runs in the TomCat web container. The back-end database is MySQL for all transactions and storage.

Future enhancements would have been user management features and more robust administration screens.

Kitchen Planner allows someone to organize recipes, plan meals, and automate shopping lists. Based on who’s scheduled to be at a meal (and any dietary needs or culinary eccentricities these people have) appropariate stored recipes are chosen. Once recipes are selected, an automatic shopping list is generated from the required ingredients.

If I were coding this application for an actual commercial product there’d be several obvious features to streamline the workflow. But, this may be useful as it is to someone. I used Access from Microsoft Office Professional to create the database application file… and I made the source file available in the mdb file format.

While using NetCentral I had noticed that it passed my encrypted authentication token value in my URL to validate my handle per HTTP request. This authentication method was an extremely bad idea for security, but back then bad ideas were common.

Once, someone “hijacked” my handle when I unknowingly clicked a link that sent them my full URL (with my authentication value). Not knowing their technique was a simple and mindless URL hijack, I wrongly thought that they had somehow broken NetCentral’s handle encryption mathematically. This made me see the encryption as breakable, and it sent me on a mission to break this encryption myself mathematically.

And I did it.

/* Program to calculate the user id code for the NetCentral
 *    chatrooms based on the actual user's handle.
 *        - Steve "WarAxe" Mooradian - 9/20/98
 */

#include<iostream.h>
#include<string.h>

void main(void)
{
	char handle[20];
	int id, handle_length;

	cout << "Input handle:";
	cin >> handle;

	handle_length = strlen(handle);

	for(int i=0;i<handle_length;i++)
	{
		if(handle[i]>=97)
			handle[i] -= 32;
		id += handle[i] * 33 * (i+1);
	}
	cout << "ID number is " << id << "\n";
}

I wrote the little routine above to calculate the authentication token for any chat handle desired… even ones that weren’t registered with the website! The authentication token is calculated by multiplying the first handle character’s uppercase ASCII value by 33, the next character by 66, and so on, and then summing the values. For example, a handle of “Axe” would have a token value calculated as follows: (A=65)*33 + (X=88)*66 + (E=69)*99.

BTW, after breaking their encryption I informed NetCentral, but they were already going to shut down the chatroom soon so they didn’t really care.