Quakeclone is a basic clone of Quake III Arena by id Software. As stated in our original project proposal, we plan to strive for technical excellence, at a cost to game play. The following reviews what work has been completed within the past few weeks, as well as the work remaining before our demo date. At this point in time, our project has the ability to load a Quake III Arena PAK file, a level inside it, as well as any player model in it. We also have the ability to render said level and player model. A simple physics model has been implemented along with collision detection. Simple weapon support has been added as well (we initially implemented the plasma gun). While networking support has been implemented, multiplayer game play is not yet complete due to other components of the application. The version of the game currently in CVS is not really a playable game. However, all of the base technology to enable the game is currently complete. Hence, a playable game is largely contingent on writing game logic code to control the various components.

• PK3 Package Loader
• Quake III BSP Level Loader
• Curved Surface Support
• Procedural Skybox Support
• Vertex Shader 1.1 Support
• Pixel Shader 1.1 Support
• Lightmap Support
• (Procedural) Texture Support
• Quake III Shader Support
• MD3 Model Loader
• Simple Physics Model
• Collision Detection / Response
• Billboard Particle System
• Networked Multiplayer Support
• Command Console Support

• Player / Weapon Collision / Response
• Player / Player Collision / Response
• Bounce Pad logic (almost complete)
• Game Logic
• Multiplayer game play

• Item Support
• Better Collision Response
• Water Physics
• More Weapon Support
• Better Physics Model

• Entity List Parsing
  The Quake III Entity List describes the entire level's environment beyond the basic BSP. Entities are objects such as jump pads, items, etc. The list is difficult to parse and so is giving us problems with our current parser.
  
• Performance hit when loading player models during game
  A new player may join a game at any point in time, before or after a game actually starts. When instantiating a new player, certain initialization is performed along with the loading of the player's model. The load of the model is an I/O intensive task. Hence, making this load a blocking function would most likely cause a large framerate loss. One fairly simple way to solve this is to make the load of the model an asynchronous task that enables the rendering of the model once the model is loaded.
  
• Some Procedural Texturing problems
  When testing the application on a different machine from which most of the graphics code was written, various glitches have shown themselves. Among them are procedural texturing problems for things such as bounce pads. These are minor bugs for the most part and we expect they will be solved.
  
• Development Time
  Finding time to develop all this code is quite difficult. We plan to make more time for this project after the Thanksgiving break and complete our game in time for the demo.

• Nov. 26: Parse Entity List
• Nov. 27 - Nov. 31: Thanksgiving Break. Minimal work, if any, completed
• Dec. 3: Fleshed out weapon support; Bounce Pad Logic; Initial pass game logic
• Dec. 5: Player/weapon collision/response; Refined game logic (including multiplayer support, respawn logic, health, ammo, etc.)
• Dec. 8: Player/player collision/response; Feature Complete (Standard Features Complete)
• Dec. 9 - Dec. 12: Debugging; Optional Features
• Dec. 13: Code Complete