Tales of the Rampant Coyote
Adventures in Indie Gaming!


(  RSS Feed! | Games! | Forums! )

Friday, February 01, 2008
 
Frayed Knights - The Stupid Stuff Takes Too Long
Tales of Frayed Knights, the comedic independent fantasy RPG coming from Rampant Games in the not-too-distant future. I hope.

It's friggin' midnight. And I just realized why my weapons are not responding properly to the armor level of the characters. Inside the character class file, I have a function that gets their armor level.

It looks something like this:

function Character::GetArmor(%this)
{
// Gets the total armor level, including current magical effects on the character.
// To Do: Everything. This is a stub.

return 0;
}

Great. Oh, well, I'm already in the middle working on equipped effects (things that happen to you while an item is equipped), so this isn't such a big deal. But it does explain a few things.

Writing Dialog. This is my favorite part of working on the game, but it isn't easy. And it is surprisingly time-consuming. Some of it works, some of it doesn't, and every single bit of it needs a major editing pass to make sure all the plot points are being hit, and that the appropriate dialogs have at least a subtle shade of humor and are speaking with the correct "voice."

Then there's allowing a "freelook" mode, but I want it to snap back to a particular pitch you are done looking around at the environment. Unfortunately, Torque doesn't give you any control over this with the Player or ShapeBase class, so I have to make a minor engine change. No big... but it takes time.

Then I spend about an hour and a half working with James to get the mount point working on his models so that the weapons aren't growing out of the back of their knuckles. James lives about 850 miles away, so much of the delay involves sending files back and forth. But part of this is just nailing down a process for us both for future content.

A crash when traveling between the dungeon and the village has me baffled. I try and trace it down in the debugger, and find it's something to do with player movement - before the level is fully loaded? It stumps me for a day. Realize that for me, a day means spending nine hours at the day job, plus a slow, snow-covered, slippy-slidey commute each way, plus an evening scheduled with other stuff that comes with having a life, not to mention a blog post, so we're really only talking about two or three hours of actual time spend working on the problem - between 2:00 AM one morning when I call it quits for the night, and 9:30 PM the following night when I get cracking again. But after a day, I realize a (possible) solution, having worked with Torque a little too long. I schedule the level load rather than calling it directly. Bam! The bad crash goes bye-bye, and everything suddenly works.

There are buttons that don't work anymore because they are properly calling the new UI manager, but I'd neglected to upgrade the call their container dialog, so it's still manually being brought into existance. The UI manager doesn't know anything about it, so the buttons aren't working. And then there are inexplicable slow-downs when certain dialogs are up. But it's bad! I need to find the problem and fix 'em.

Grumble.

While the entire first chapter is, as of last night, playable from beginning to end, there are a couple of major issues still outstanding. Like, oh, saved games. And trading. A new and improved inn. But for the most part, we're down t0 "stupid stuff," which takes almost as long as the big tasks. All those little details that might fall through the cracks. And there's a LOT of it. It's those stupid, little things that take so much time, paralyze apparent progress, and drive me crazy.

I hate this part. And it's not even in the serious bug-fixing stages yet. This is the point in the project where keeping an updated "to do" list is critical, and where you have to take satisfaction from seeing lots of little, stupid things marked off as "complete." Because it doesn't make great screenshots, and the players won't notice it at all unless it's not done right.


Forum Discussion, Because Misery Loves Company

Labels: , ,



Did you enjoy this post? Feel free to share it: del.icio.us | Digg it | Furl | reddit | Yahoo MyWeb

Comments:
Ah, forgotten stub functions. What a pain. When I work on a large project, I often have each stub function write to stderr, just as a reminder that they're still there.

I hope you're OK with all the snow. A friend of mine in SLC got the day off work today because of it -- presumably the roads are bad?
 
I was very tempted to call it in today, because the roads were so bad. I went in anyway, because my boss was supposed to have a mechanics review with the programmers and designers today.

It took me an HOUR to get in. But no, my boss wasn't there. He took the day off to go snowboarding.

D'oh!
 
I love the detail on the masks in the second screen shot. I didn't really notice it last time you posted shots of the cultists.

Oh, and I love the . . . umm . . . testing in the combat. It looks very, well, tested . . .

It really is hard to appreciate this stage of game design. Even in the world of programming, it's the artists and not the coders who get all the attention.
 
LOL! Yeah, that's how it goes, though. And pretty much where it'll be from here on out, now that the core mechanics are about 90% done.

Pretty much all of March is gonna be polishing and debugging, too, which is going to be even worse. 'This is what was already covered before... but see, this has a smoother transition, and we fixed a bug where, if you came here straight from the inventory screen, the character's picture was wrong..."
 
Post a Comment

Links to this post:

Create a Link



<< Home

Powered by Blogger