Frayed Knights Dev Diary: It's All in the Details
This week included camping and Independence Day celebration, so indie game development this week was a little on the slow side.

So there I was, trying to clean up combat, animate the bad guys properly, and I noticed on my fairly beefy machine (a dual-core AMD 3800+ machine with a gig of RAM and a pretty decent video card) that the framerate noticeably crawled when all four bad guys were on the screen at once. This wasn't so noticeable inside the dungeon itself, but when the portal was in view (with all the trees and outdoor geometry) it was painful.

Hmmmm... and I'd intended to have as many as twelve enemies at a time. This could be a problem. My best suspect was the sheer number of polygons. A quick analysis of the skellies (I'm using the DrewFX Skeleton Pack) in the ShowTool made me realize the problem.

Details, Details
In 3D games, there's this thing called Level-Of-Detail (abbreviated LOD). This is where a model actually has several different detail levels, and the game picks which one to display. Traditional LOD, which the Torque Game Engine uses, bases the detail on the distance from the camera (or - in Torque's case - the actual size of the model on-screen. Which is kinda cool). There's just no sense in having a detailed 5,000 polygon model for something that is only taking up 20 pixels of screen real estate.

There's another form of LOD sometimes called "Dynamic LOD" or "kLOD" which renders the detail levels of everything on the screen based on framerate. So if things start slowing down, the game will "dial down" the detail level on everything to improve performance. Unfortunately, Torque doesn't have this (that I know of), and doing it right usually requires some standardization across all of your 3D assets.

Since all four skeletons are front-and-center, they were all appearing at the highest, or near-highest, level-of-detail. This introduced somewhere around 12,000 extra polygons to the scene. And of course, there were the swords, too.

That might explain a slow-down. The next thing I tried to do was to find out if there was a way to force the skeletons to a particular level-of-detail. Methods exist in the Torque Game Builder (TGB - formerly Torque 2D) to do this, and a similar method existed for structures. But for DTS (Torque's format name for generic meshes) objects? I remembered playing with the slider bar in the old Torque demo to see the progressive LOD changes in Kork, so I thought (and still think) such a beast may exist, but I could find nothing documented. Nor did anybody on the forums know anything about it. Nor did digging through the source code.

So I rolled my own. A process which took less time than I'd spent trying to find the answer in the first place. I simply added a variable to ShapeBase, and caused the rendering loops in ShapeBase and Player to override the results of the normal L.O.D. call with this value if it has been set to a positive or zero value. Of course, nothing is this simple with engine-level changes. Besides making sure the variable was initialized properly, and accessible in C++ code, I also had to add console functions to access it via TorqueScript, and to pass it from server to client.

Unfortunately, the Skeleton pack skeleton's lowest LOD still clocks in at around 1800 polygons - still pretty beefy (and pretty awful-looking close-up, I might add). I was still noticing the framerate hit, though not as badly. Then I took a look at the sword.

Now That's a Big Sword!
I had to modify the weapons (from the Tridinaut Medieval Weapons Pack) once before to fix the pivot point so they wouldn't mount above the skeleton's hand. This took an import, as almost nobody likes working with Blender (even though it's... like, you know, FREE and stuff). I'd imported from another format --- always a chancy operation --- and either through a fault in the import or my own stupidity, I'd lost the level-of-detail information and only exported the sword at the highest LOD. Which clocked in at over 450 triangles. To make matters worse, I'd neglected to turn off double-sided polygons, which doubled the final poly count in-game to over 900 polygons. So the four swords were contributing nearly an extra 4,000 polygons to the scene.

Add that to the mess of LOD-less trees and so forth in the forest visible through the portal. Ouch. I'm still not convinced that tells the whole story, but by fixing the swords and forcing the skeletons to a passable (but not the lowest) LOD, I've lessened the problems. I'll need to go back and see if I can re-import the weapons with their detail level information intact.

And a Dash of Gameplay on the Side
On the less technical side, I implemented resting. Not taking-a-nap-in-the-dungeon resting, but pausing during combat to catch one's breath and regain endurance. I've changed some UI elements around to make combat less irritating to play. Under construction (but not complete as of the time of this article) is a system to "advance" the ranks of monsters if an entire rank in front of them have been wiped out.

In case you are interested, here are my goals for the month of July:

• COMBAT SYSTEM - spells, feats, more advanced AI (which use spells & feats, and recognizes the "ranks" within the player party)
• Interactive Object system
• Modeling of the first 3 areas of the test dungeon *complete*
• Revised Movement System
• Pick Up Treasure
• Drama Star System - Star Point Acquisition
• First Five Minutes of Gameplay.... COMPLETE!

Chatter Away on the Forum!

Labels: Frayed Knights, Roleplaying Games

- posted by The Rampant Coyote @ 12:07 AM (Permalink)