3D Pool Table Futures

Sound & Networking:

• Generate scraping sound when the cue hits the felt. This will help to keep the cue above the table. It would require a scrape_on and scrape_off packet to the sound server. The sound server could convolve on location, or it could generate a static sound.
• Volume adjustment should be done with a slider widget. Master volume should be communicated to the sound server to adjust cd sound & previous sound effects currently in progress.
• The textures take time to load, and they are loaded while reading the config file. The config file also specifies whether sounds should be loaded or not, so sound cannot be started until after the textures have loaded. The sound server takes a few seconds to start, so these delays should be overlapped. This could be done by loading textures AFTER reading the config file.
• We need to add cd player on/off buttons.

Gameplay & Human/Computer Interaction:

• Generate a slider widget to allow the user to adjust 1D parameters. Utilize this widget in adjusting parameters of all graphics objects, and gameplay paremeters. This could include cue length, volume, elasticity, etc. This would also allow run-time tuning, which is sorely needed when many parameters interact.
• Finish sticky buttons. These allow the user to select a button that stays selected and modifies the behavior of the stylus until it is de-selected. For example, the user could select "translate table". The log window should show instructions on what to do. Next the user could move the virtual cue to a point on the pool table, and press and hold the stylus button. At this point the virtual cue should change to a translate icon, and all movement of the stylus should move the table in all 3 dimensions as well. Releasing the button should cause the virtual cue to return and cause the location of the table to stop tracking the stylus. This method would allow a user to make adjustments, play a bit, fine tune them, etc without having to return to the menu buttons to deactivate the sticky button until they are done. Alternatively, we could change the virtual cue icon as soon as the button is selected and disable normal pool play. This would be more obvious to users, but more tedious for tuning. Perhaps this behaviour could be an option, and advanced users would pick the second mode. Making changes while the button is depressed allows us to "ratchet" our changes because our reach is finite. If carpal tunnel is a concern, we could change it so that a click turns on ratcheting and a click turns it off. This would be easier on the user, but perhaps less intuitive. The log window is meant to help explain things, perhaps it would be enough.
• Utilize sticky-buttons to allow the user to grab the pool table and rotate, translate, and scale it in real time. The user should also be able to grab pool balls. As the table is adjusted, we need to make sure that the sound server gets the correct transform matrix.
• Help text would be best served in a scrolled window, instead of putting it in the log window. This would require a scrolled window widget.
• Gameplay could be modified from it's current free-form into a set of rules that are enforced on the user. The user could then pick any number of playes & select a game & be assured that they are playing the game right.
• It would be nice to be able to "undo" and "redo" moves caused by hitting a poolball. It would also be nice to be able to save and load games.

Graphics:

• Each object currently has RGB values, a material, and a texture. These values have been tuned so that they look good with all features turned on. With any of them turned off, they look bad. We should specify that RGB is only used when materials & textures are off, give textures their own material (so that lighting & no textures looks good) and give textures their own RGB values for when lighting is off. It would be best to put these values in their own object, and use a common routine to setup the graphics when drawing each object. This would allows us to compare the effects of each of the combinations lighting/textures/shadows on and off.
• The game takes about 30 seconds to load. It would be nice if we put up a simple gfx screen with a single log window, and wrote messages to the log stating the progress of the load.
• The config file uses a single table directive that combines positions and color information. It should be split into 2 directives and each should be given a number. The user should be able to change "color sets" and "table layouts" at run-time. This should be easy to do, and the results would look great. The table could go from marble to a wooden look, poolballs could become metallic, or have faces on them, and the table could change so that we had our choice of size (for easy continous rotations) and vertical position as noted in the tradeoffs.
• We could change the table generator to allow a different number of holes to allow holes in the middle of the table, etc. This feature needs the table selection feature, as it shouldn't be our primary table.
• One side of the bumpers is missing. The poly is probably draw cw.
• Shadows should clip on the side of the table. They should also cast shadows over other parts of the table besides the felt. A texture map of graduated alpha values could be used to cause the shadows to cancel out the light from which they are cast correctly, and not cast a shadow outside of the spotlights cone.
• The felt & holes should be mapped as actual 3D polygons. Lighting should cast shadows into the holes.
• The balls should have set animation modes, when actual physics is turned off. For example, hitting a hole should animate the ball into the hole, and then animate the ball over to the ball return area.
• Poolballs should cast shadows.
• On-line config could have textured buttons to allow the user to change the texture for any surface.
• A real pool table has stars on the outside surface and markings on the felt to aid in placing the pool balls.
• Draw a sphere or a funky polygon where the lightsource is. They are not visible, but they will become visible as the use moves the table down or modifies parameters online. If the light sources are visible, we could grab and move them.

Physics:

• If physics is ever predicted, we could tell the sound server in advance when a sound would occur. If the sound server also predicted head location, we could generate sounds with no latency. The latency is pretty small now, so this may not be worthwhile.

See Also:

• What were the major tradeoffs?
• Return to the pool page.