June 27 (Profiling Performance, Please!)

The past week was a productive one. The Find & Retrieve gametype was rewritten, a slew of GUI work was completed and I did some early (but important!) performance profiling for the game.

The F&R gametype was a fairly easy piece of work thanks to a straightforward design. The design doc called for the basics of a Find & Retrieve mode: an object to be found/collected by players and a "collector" where players could dump these objects. What I ended up with were Nanites (the object to be collected) and Nanite Reclaimers (the collectors). Going in, I didn't want the F&R mode to degenerate into a "find the Nanites faster than the other team" game. I didn't want the ultimate strategy to simply be put everyone on offense and grab as many Nanites as possible before the other team while avoiding combat if at all possible. Instead, I wanted the gametype to reinforce player-vs-player battles; to create "hotspots" around Nanites where players would fight over it. To accomplish that, the design called for several things:

• Many Nanites to be placed on each map but in strategic locations (i.e. one might be near each team's base while another might be in the center of the map; creating two "easy" grabs and one "hotspot")
• Giving players the ability to "throw" Nanites to other team members (or possibly have them intercepted by enemies)
• Being hit by a forcebolt to cause the player to drop a Nanite (assuming they're carrying one)

I also wanted F&R to be as balanced as the Capture & Hold gametype if possible. That meant making both offense and defense important. To reinforce this concept, the design called for allowing captured Nanites to be grabbed by enemy players. If a team wants to be successful at F&R, some players will need to guard the captured Nanites/Nanite Reclaimers (play defense) while others will need to seek out the remaining Nanites (play offense).

Some rather boring but necessary GUI work was also completed. Namely, the map loading screen and the end map screen. The loading dialog now fits with the rest of the interface and displays some important server and map information. The end game interface shows player and team scores, which map was being played, which team won and the time it took to win. As I said, pretty boring stuff really but it's now (thankfully!) checked off of the todo list.

And lastly, the performance profiling. Performance in the game has never been bad (always above 30 FPS at 1280 x 1024 x 32 resolution on a mid-high end PC) but I have always known it could be better, just not sure how. Thanks to Torque's nifty profiling system, I quickly found out: shadows. With a full (16 player) team of hovertanks on the map, framerate dropped to below 30 which was unacceptable. The profiler showed that nearly 18% of the total game time was being spent inside the dynamic shadow renderer. After a couple quick searches, I happened across a very nifty resource that overhauls the system making use of some newer hardware. Porting it over to my version of TGE was a bit of a pain but once done, the profiler showed the new shadow code was taking less than 1% of the total game time on the same map! Such a massive improvement resulted in an extra 9-10 frames per second which was a pleasant surprise. There's still a few kinks to work out and some cleanup to be done but nothing gamebreaking.

As for the week ahead, Lord willing, I'll be working on getting the first map started and finishing some more GUI stuff. Until next time!