Screenshots

The start screen	Politi-Pong in action; Geroge W. Bush level

Features

• Designed for Windows (ready-to-run with no dependencies, unless you want to self-compile) and Linux (compilation needed)
• Face five opponents of increasing difficulty: George W. Bush, Bill Clinton, George H. Bush, Ronald Reagan and Jimmy Carter
• The game has been play-tested for quality and is completable--defeat all 5 to become Politi-Pong master
• Listen to the presidents' taunts and exclaimations during gameplay, sampled from real audio of their public speeches
• A/I is designed to be realistic
• A complete scoring system with saved high scores
• Simple, low-key, uncomplicated gameplay--at its heart it's still Pong
• The Linux version has no dependencies other than plain SDL; it also features some automation in getting sound to work, trying multiple methods if necessary
• Though not used in the game, the source files include working ALSA soundserver classes for Linux

Download

The game can be downloaded from its home at SourceForge: Politi-Pong.

About Politi-Pong

Play pong with the presidents. Look for openings to score and win the round.

The source code is based on a 2005 game called PongNotPong by Mathew Hurne. It is written in C++ and includes a class diagram. The purpose in writing it was mainly for self-teaching--developing a better understanding of C++ and object oriented programming.

A History of Computer Table Tennis Games

The earliest electronic ping-pong game was played on an analog computer using an oscilloscope as a display, and was developed by William A. Higinbotham at the Brookhaven National Laboratory in 1958. His game was called Tennis for Two.

In September 1966, Ralph Baer, then working for Sanders Associates, wrote a short paper outlining a system for playing simple video games on a home television set. Originally, his chief engineer Sam Lackoff asked Baer to build a television set. Baer decided to add the new concept of playing games on a television screen. He developed a computer version of a ping-pong game, and his ideas were patented. Magnavox licensed the technology from Sanders Associates, and in the middle of 1972, the company began selling the Magnavox Odyssey, the first home video game console. The Odyssey was capable of playing a dozen different games, including a basic version of table tennis and a slightly more complex version of tennis.

Meanwhile, with a starting capital of $250 each, Nolan Bushnell and Ted Dabney founded a new company in 1972 which they named Atari, Bushnell was concerned that his pioneering 1971 video arcade game, Computer Space, had been too complicated for some users. In an interview, he said of the game: "You had to read the instructions before you could play, people didn't want to read instructions. To be successful, I had to come up with a game people already knew how to play; something so simple that any drunk in any bar could play." Atari's version of computer table tennis is technically the only version that can properly be called "Pong" (trademarked). The coin-operated arcade game was released by Atari on November 29, 1972.

From the readme...

What You Need to Run the Game

1. for Windows nothing extra is needed, other than
   1. ensuring the executable is in the same directory as the "data" folder
   2. the SDL.dll and SDL_Mixer.dll are either in the same folder as the executable OR SDL.dll and SDL_Mixer.dll are in your windows/system directory
2. for Linux
   1. you'll need to compile* it (see below for details--a g++ specific Makefile is given, to make the process easy and g++ can be downloaded if you don't have it), for which you'll need the SDL-develop package installed
   2. you'll need to have SDL installed (just the basic SDL package--no additional add-ons like the SDL mixer (the mixer is only used in the Windows version), etc...)
   3. as with Windows, you'll need to ensure the "data" folder is in the same directory as your executable

Compiling on Your Own (for beginners)

Linux

To install under Linux, you can use the included makefile if you download the g++ compiler. You'll also need to download SDL (you'll need BOTH the SDL-develop package to compile and the SDL package to run the program) if you don't already have them. Then, extract the source archive called src_linux (this can be done, for example, from the GNOME or KDE desktop). Open a shell (Applications>System Tools>Terminal, for example, in GNOME) and navigate to the (extracted) directory labeled "src_linux". Once there, type in the command "make" at the shell prompt. After the compiler is done (you may get several "linker input file unused because linking not done" messages during the compile--ignore them), an executable file called "PolitiPong" (no dash between Politi and Pong) should appear in the "src" directory's PARENT directory. Extract "data.tar.gz" into the same file as the "PolitiPong" executable and then, while in that directory in the shell, type: "./PolitiPong" (adding any audio command line switches if desired--see below for sound troubleshooting) and play.

What's a make file?

This is the conductor (as in orchestra) to get everything compiled easily (you COULD, for example with g++, type in a (really) long line at the command prompt to get things to compile; the make file just reduces the workload). The "make" utility is smart in that it will automatically look for a file called "Makefile" (with one or two variations) in the directory from which it's run and execute the instructions it finds in this file (there is an option, though, to specifiy which counductor-file to use for the "make" utility--eg "$make -f [filename]").

Why won't it compile under Linux?

So you've run "make" and you don't get a successful compile? I can say at least, it compiles on a (normal?) version of Fedora Core 8 (as mentioned, you need to have g++ and SDL installed for the included Makefile to work). Beyond that, it's probably up to Google to find out why it won't compile. (Every effort has been made to reduce peripheral libraries and to keep the code to platform independent C/C++ standards. However, I'm told that what compiles on one machine may need some tweaking to compile on another.)

Windows

If you want to (or need to) compile the code on your own, you can use VC++, adding all files in the extracted "src" directory into a VC++ project (just add them in one big group into a new VC++ console application). If you haven't already done so, you'll need to download the SDL developer libraries (be sure to get the mixer library and include files too) from the SDL site and inform Visual C++ about SDL (there are several good resources online for how to get VC++ to compile with SDL (for example this tutorial)--briefly, it involves

1. telling VC++'s "include directories list" about the "include" folder in the SDL developer downloads
2. telling VC++'s "lib directories list" about the "lib" folder in the extracted download*
3. setting VC++ to "multithreaded DLL" in the C++ code generation menu (this is important since the SDL.dll itself has been compiled with this option "selected" and mixing and matching compiled code with different threading options can create problems)
4. putting the SDL.dll and SDL_mixer.dll in a spot where your compiled program can find it (either in the same directory as your executable or in your Windows/System folder)
5. also, building the RELEASE version seemed to work better than building the DEBUG version.
( *NOTE: at least in Windows 98, it seemed necessary, in addition to the above, to add (Project>Add to Project) the SDLmain.lib and SDL.lib files to the project itself (so they appear with all the other source and header files in the project); not adding the SDL_mixer.lib didn't seem to produce problems)

Troubleshooting

Problems on Windows

1. a Windows 98 machine failed on all SDL video applications (gave a general protection fault on SDL_Init for video)
2. a Windows 98 machine ran video; sound worked but was low quality
3. a Windows XP laptop ran video and sound but the video suffered from sprites blurring (becoming nearly transparent) at high speeds (this might be from the type of LCD display, though it was supposed to be an active display)
4. a Windows XP desktop ran video and sound successfully

Windows Audio

If your audio is not working in Windows, it appears compiling an SDL application in Windows makes the audio default to DirectX audio, so DirectX audio must be working properly (though you might have some luck with the command "set SDL_AUDIODRIVER=wavout" at the DOS command prompt just before running the executable from the same prompt--no promises on latency however...). In fact, if the program freezes any time before showing the actual splash screen, the audio may be the culprit--if all else fails, run with the switch "-s NONE" to at least get the graphics portion of the game running.

Problems on Linux

Linux and Jerky Animation

If you're running Linux and you get jerky animation, try turning off X-server-heavy applications. For example, on a Pentium III running Fedora Core 8, noticeable jerking is evident in the ball/head motion across the screen if MythFrontEnd is running (even idling) or if MythBackEnd is recording (even if MythFrontEnd is off). You can try to find the cluprit(s) by running "top" but it seems even certain low CPU % processes can hamper smooth animation.

Linux and Sound

If your audio is not working in Linux, you can try running the game from the command line, using the switches to manually tell SDL which audio system to try.

(NOTE: for Linux, audio was designed to be robust; it was designed with the novice Linux user in mind; its default mode is to run an auto-find search (by trying different SDL_AUDIODRIVER variables--the inital version of this game has it trying its "default" setting, then the "alsa" system and finally the "dsp" device) to get sound working--the auto-find search though is not exhaustive and/or might not snag the audio application you want it to use--you may still get audio results and/or can set it using the correct device name in the command line switch)

1. switch syntax
• -s [server name] the possibilities are: "NONE" and "SDL"
• -d [device name] for SDL, the 'devices' are simply the SDL_AUDIODRIVER environment variable listed below
• examples
• example of command line launch--navigate to the game's directory then: [@shell prompt]./PolitiPong -s SDL -d dsp
• example to turn audio OFF, run from the command line with the "-s NONE" switch (sets audio server to NONE): that is, once in the game's directory, type: [@shell prompt]./PolitiPong -s NONE
2. list of SDL supported audio systems (used for the -d switch argument; case sensitive)
• openbsd (OpenBSD)
• dsp (OSS /dev/dsp: Linux, Solaris, BSD etc)
• alsa (Linux)
• audio (Unix style /dev/audio: SunOS, Solaris etc)
• AL (Irix)
• artsc (ARTS audio daemon)
• esd (esound audio daemon)
• nas (NAS audio daemon)
• dma (OSS /dev/dsp, using DMA)
• dsound (Win32 DirectX)
• waveout (Win32 WaveOut)
• baudio (BeOS)
• sndmgr (MacOS SoundManager)
• paud (AIX)
• AHI (Amiga)
• disk (all; output to file)
[a user familiar with SDL might realize these to simply be the SDL_AUDIODRIVER environment variable options; this IS what they are; the game will try to set and unset the SDL_AUDIODRIVER environment variable in the program's audio routines (note: if it does make a change, it is not 'exported' and it is designed to restore the environment variable back to its original value on program exit)]

(for Linux users, a note about ALSA: In the interests of redundancy and in getting audio to work the first time, every time, an attempt was made to use a stand-alone ALSA sound server (though not used here, the class for this server is in the source code in the SoundSystem folder), that would run simultaneously with SDL (bypassing SDL's audio routines); this attempt was not successful. It may be that SDL's signal handling system interfered with the attempt at stand-alone callback driven ALSA support. The callback-driven ALSA sound server class was functional outside SDL and may be of interest to other developers. For now, ALSA is accessed ~indirectly through SDL's audio interface.)

Class Diagram