Cutting my losses
by Daniel Buckmaster · 10/28/2009 (3:32 am) · 10 comments
I just made a huge leap forward with my advanced Player class! How, you ask? By not doing something that was going to take me months! It’s brilliant...
I’ll try to cut out as much sob-story I can, but the long and short of it is, I sat down to get cracking on my new Player class with animated collision meshes, and... got nowhere. I realised that I really had no idea what to do about the awful bugs I had introduced.
While I was ecstatic even to get the code working, since I had completely gutted the Player collision system and hacked in a new one that *nearly* worked, it just wasn’t working well enough. Players would mysteriously fall through the terrain, jitter when standing still, collide with invisible edges – and the performance hit when approaching an interior was disgusting.
They were all issues I could tolerate – if I hit an invisible crack in the terrain and skated for a while, I would patiently wait until the player floated low enough for contact to be made, and continue on my way. I avoided Interiors. Then I took a step outside my own head and thought about two people: the end user of my game, and the GarageGames user who might be interested in my code. It didn’t seem fair to either of them to want to force such a buggy system into the game.
Simple, fix the bugs! But that’s what I’d been trying to do for the last several months. Again and again I had tried different solutions, looked at different suspect functions, tried to reason out what was happening, debug with VC++ and with $timeScale. But nothing was successful.
So I had a choice.
1. Spend the next few months or more working out the bugs, either by replacing the parts of the code that don’t seem to be working (which… I’m not sure about anyway), patching, or somehow actually debugging the issues I do have.
2. Scrap it.
Option two seemed more attractive by far.
Because I think I’ve figured out… it’s not worth months and months of my time to code things my way, when I can easily code it a different way, and move on. And believe me, after so long staring at my character sliding along up to his knees in the ground, I am itching to move on. The final nail in the coffin was that I could probably implement all the functionality I wanted without my handy-dandy collision system. Not the way I wanted it implemented, of course, but sufficiently well for it to work – and that’s the important thing. I’ve sort of come to appreciate that even though the system might not be the ideal method that I can see in my head, it will work.
I hope that’s a lesson learned – definitely for me, and hopefully anyone else struggling with something like this. There’s that old joke about the doctor – “doctor, it hurts when I do this!” “Then stop doing it.” If it costs you too much to do something, then maybe you should re-evaluate. Do you really want to do it? And if so, is there an easier way?
I’ll try to cut out as much sob-story I can, but the long and short of it is, I sat down to get cracking on my new Player class with animated collision meshes, and... got nowhere. I realised that I really had no idea what to do about the awful bugs I had introduced.
While I was ecstatic even to get the code working, since I had completely gutted the Player collision system and hacked in a new one that *nearly* worked, it just wasn’t working well enough. Players would mysteriously fall through the terrain, jitter when standing still, collide with invisible edges – and the performance hit when approaching an interior was disgusting.
They were all issues I could tolerate – if I hit an invisible crack in the terrain and skated for a while, I would patiently wait until the player floated low enough for contact to be made, and continue on my way. I avoided Interiors. Then I took a step outside my own head and thought about two people: the end user of my game, and the GarageGames user who might be interested in my code. It didn’t seem fair to either of them to want to force such a buggy system into the game.
Simple, fix the bugs! But that’s what I’d been trying to do for the last several months. Again and again I had tried different solutions, looked at different suspect functions, tried to reason out what was happening, debug with VC++ and with $timeScale. But nothing was successful.
So I had a choice.
1. Spend the next few months or more working out the bugs, either by replacing the parts of the code that don’t seem to be working (which… I’m not sure about anyway), patching, or somehow actually debugging the issues I do have.
2. Scrap it.
Option two seemed more attractive by far.
Because I think I’ve figured out… it’s not worth months and months of my time to code things my way, when I can easily code it a different way, and move on. And believe me, after so long staring at my character sliding along up to his knees in the ground, I am itching to move on. The final nail in the coffin was that I could probably implement all the functionality I wanted without my handy-dandy collision system. Not the way I wanted it implemented, of course, but sufficiently well for it to work – and that’s the important thing. I’ve sort of come to appreciate that even though the system might not be the ideal method that I can see in my head, it will work.
I hope that’s a lesson learned – definitely for me, and hopefully anyone else struggling with something like this. There’s that old joke about the doctor – “doctor, it hurts when I do this!” “Then stop doing it.” If it costs you too much to do something, then maybe you should re-evaluate. Do you really want to do it? And if so, is there an easier way?
About the author
Studying mechatronic engineering and computer science at the University of Sydney. Game development is probably my most time-consuming hobby!
#2
I considered that, but my changes are pretty extensive. I've tagged the last revision I had in my repository, though, so I can dig out the code if anyone sees this and offers to take a look ;).
10/28/2009 (6:08 am)
Yep.I considered that, but my changes are pretty extensive. I've tagged the last revision I had in my repository, though, so I can dig out the code if anyone sees this and offers to take a look ;).
#3
10/28/2009 (7:08 am)
That's the joy of software development - months of banging your head against a brick wall before a single divine moment makes you realise there's another way. 
#4
10/28/2009 (9:22 am)
I was never in to doing coding stuff like this, im sure i can paint a picture that would show your frustration: 
#5
What kind of functionality do you want to achieve ?
Before changing the collision stuff, first you should understand how it works at all.
10/28/2009 (9:56 am)
Daniel,what is the deal with your animated collision meshes ?What kind of functionality do you want to achieve ?
Before changing the collision stuff, first you should understand how it works at all.
#6
In a forum here, time ago, a fellow member taught me: we are always more in danger of not finishing the work, than anything else. The wise path, is not always the technical perfect path.
10/28/2009 (10:33 am)
Excellent read Daniel.In a forum here, time ago, a fellow member taught me: we are always more in danger of not finishing the work, than anything else. The wise path, is not always the technical perfect path.
#7
Give up on doing things the "right way" when they'll take a long time to do.
If it looks right, it is right.
10/28/2009 (5:05 pm)
I'd say this is the most important truth in game development.Give up on doing things the "right way" when they'll take a long time to do.
If it looks right, it is right.
#8
The important thing is that right now you should have way more knowledge on the engine than most Torque users and that will help you in any future attempts to create your own player class.
Luck!
10/28/2009 (5:36 pm)
Sometimes we just get lost in the branches. I dont remember how many time I have scrapped something which was getting too complicated. It is usually the right thing to do and allows to see everything on a new light.The important thing is that right now you should have way more knowledge on the engine than most Torque users and that will help you in any future attempts to create your own player class.
Luck!
#9
I do have a question. What was the overall objective of the animated collision meshes? I think I understand what you were looking for, but not sure.
10/28/2009 (9:23 pm)
@Daniel good post. For me GG (or whatever they are called now:)) is releasing new engines and updates faster than I can finish a single project. But for me it's all about learning and sometimes redirection is part of it.I do have a question. What was the overall objective of the animated collision meshes? I think I understand what you were looking for, but not sure.
#10
Matt - that about sums it up :P
With respect to what I was trying to achieve:
I set out to replace the Player collision detection/resolution scheme with the same method that Vehicles and RigidSHapes use. Instead of using a datablock-defined box that is not allowed to intersect any world geometry, Vehicles use artist-defined convex meshes for collision detection, and resolution is accomplished after movement by penetration penalties (i.e. if after you've moved, you find you're penetrating geometry, apply an impulse to move you out of it).
On top of that, I wanted to support multiple collisoin meshes (Vehicles currently only use one), and have the ability to animate the meshes. That would mean that the meshes could change dynamically to support different stances. It was also how I was going to handle things like mantling - move a collision mesh down in front of the character like a pair of arms, and the character will be bumped up on top of any geometry that's there.
Picasso - I understood enough of the system to replace it, but not enough of the detailed stuff to understand why it wasn't working. I guess that was my problem - I thought I could plug in the Vehicle system without a deep understanding.
10/28/2009 (10:16 pm)
Thanks for the comments, guys. Good to know I'm not *just* a quitter ;)Matt - that about sums it up :P
With respect to what I was trying to achieve:
I set out to replace the Player collision detection/resolution scheme with the same method that Vehicles and RigidSHapes use. Instead of using a datablock-defined box that is not allowed to intersect any world geometry, Vehicles use artist-defined convex meshes for collision detection, and resolution is accomplished after movement by penetration penalties (i.e. if after you've moved, you find you're penetrating geometry, apply an impulse to move you out of it).
On top of that, I wanted to support multiple collisoin meshes (Vehicles currently only use one), and have the ability to animate the meshes. That would mean that the meshes could change dynamically to support different stances. It was also how I was going to handle things like mantling - move a collision mesh down in front of the character like a pair of arms, and the character will be bumped up on top of any geometry that's there.
Picasso - I understood enough of the system to replace it, but not enough of the detailed stuff to understand why it wasn't working. I guess that was my problem - I thought I could plug in the Vehicle system without a deep understanding.
Associate Tom Spilman
Sickhead Games
I would suggest posting the code to the forums... someone may want to jump in and help you fix it.