How to plan code
by Alpha-Kand · in General Discussion · 12/26/2012 (11:39 am) · 5 replies
I have been trying lately to make a clean and compact platformer engine with the works. I didn't really plan anything because I just wanted to make a platformer engine for the moment (I guess that's what you would call it). In a way I was almost done with the character being able to double jump, speed up and slow down when moving, wall jumping, special wall climbing (in case I should ever want it), ducking and sliding.
It was so not-buggy, compact and beautiful! *sniff*
Then came slopes... 5+ FAILED attempts at trying to get a silly square to run, stop and jump on slopes. Each time I made a backup and just about started over with a new idea.
The real question is, how does one plan something like this and see possible disasters? I couldn't foresee half of the problems I would come across and potentially messy worthless ideas.
I have heard about pseudocode but I am not sure that would help here. Experience takes time. What have you found that works?
It was so not-buggy, compact and beautiful! *sniff*
Then came slopes... 5+ FAILED attempts at trying to get a silly square to run, stop and jump on slopes. Each time I made a backup and just about started over with a new idea.
The real question is, how does one plan something like this and see possible disasters? I couldn't foresee half of the problems I would come across and potentially messy worthless ideas.
I have heard about pseudocode but I am not sure that would help here. Experience takes time. What have you found that works?
About the author
I have always loved video games and computer games so decided to try making my own. Spent a little more than a year on a program simply named Game Maker which really got me interested. Finally decided to get "professional" by getting Torque 2D.
#2
@alpha,
Often times the biggest challenge of a problem is the wrong mental model or an insufficient mental model of the problem. Write down the problem. This will force you to make clear the mental model. That is one reason I liked dBs thought process because he is doing that. I forget to do this. I get frustrated and post on some forum like GG about the issue. Then, because I posted about the issue my mind gets a clearer mental model of the problem which leads to a solution. This is why you will see posts from me that has me solving the problem within a few hours. I try not to do that, but some habits are hard to break.
I also tend to rewrite a lot. For ScriptT3D I rewrote it 3 times before I felt it was a really solid release. Before I wrote that I ported the PyTorque code to T3D which gave me some insight on how to write my own. Right now I am rewriting my loopback capture code. I have a partial rewrite that I am going to scrap because it has become hopelessly complex and prone to failure. It has become a giant threaded mess that I would be embarrassed to release.
As to the problem? I don't know exactly what you are doing so please forgive my ignorance. Oh, and BTW, T2D may be a more mature platformer platform when it comes out next month (hopefully, crossing fingers).
Would it help to represent the level as a series of points to represent the walking surface? That way you can basically do collision against each line segment of the 2D terrain.
12/26/2012 (5:08 pm)
Quote:...write a quick Python script instead...Bonus points for dB on this one. This can provide a nice reference implementation as it really strips away most language dependent concepts like memory allocation, pointer crap, etc.
Quote:...and not try to keep it all in your head...I agree, take notes as you work through things and write down other possibly routes even if not taken at the time. Sometimes knowing what doesn't work is more important than knowing what does work.
Quote:...don't be afraid of rewrites...Expect rewrites. I generally prototype, rewrite, rewrite, ... Until I am satisfied the code is clean, well designed, maintainable, and modular if possible.
Quote:...maybe I'm not the best role model to follow here...Sorry to hone in on your quotes dB. Your answer is so spot on. You definitely are a good role model.
@alpha,
Often times the biggest challenge of a problem is the wrong mental model or an insufficient mental model of the problem. Write down the problem. This will force you to make clear the mental model. That is one reason I liked dBs thought process because he is doing that. I forget to do this. I get frustrated and post on some forum like GG about the issue. Then, because I posted about the issue my mind gets a clearer mental model of the problem which leads to a solution. This is why you will see posts from me that has me solving the problem within a few hours. I try not to do that, but some habits are hard to break.
I also tend to rewrite a lot. For ScriptT3D I rewrote it 3 times before I felt it was a really solid release. Before I wrote that I ported the PyTorque code to T3D which gave me some insight on how to write my own. Right now I am rewriting my loopback capture code. I have a partial rewrite that I am going to scrap because it has become hopelessly complex and prone to failure. It has become a giant threaded mess that I would be embarrassed to release.
As to the problem? I don't know exactly what you are doing so please forgive my ignorance. Oh, and BTW, T2D may be a more mature platformer platform when it comes out next month (hopefully, crossing fingers).
Would it help to represent the level as a series of points to represent the walking surface? That way you can basically do collision against each line segment of the 2D terrain.
#3
Before I sound a whole lot more awesome than I really am I have Torque 3D for the future but for now I am using TGB. :)
Luckily that doesn't take a lot of math. Probably the most math needed is calculating the slope of an angle and where to y offset an object based on the slope and current position x position.
I have found out that using constant force is NOT the way for Me to go. Setting vertical speed works better for me but you can't find that out when just planning your game...
NOW I can't get the object to fall on a floor when going at a good clip and meet it perfectly without the character hovering a little above the floor. Pressing a debugging key that dynamically turns on the gravity while the object is hovering has the object fall into that tiny space and meet the floor perfectly. :S
12/26/2012 (5:37 pm)
EDIT: Everywhere I look the pattern for planning seems to be more or less the same. It's reassuring in a way to know I'm not a failure by having to rewrite code all the time. :) Most of my problems are in the collisions. Not with the slopes by themselves but going from floor to slope or slope to floor or slope to different angled slope. Or colliding with walls while on slopes. I guess colliding in general.Before I sound a whole lot more awesome than I really am I have Torque 3D for the future but for now I am using TGB. :)
Luckily that doesn't take a lot of math. Probably the most math needed is calculating the slope of an angle and where to y offset an object based on the slope and current position x position.
I have found out that using constant force is NOT the way for Me to go. Setting vertical speed works better for me but you can't find that out when just planning your game...
NOW I can't get the object to fall on a floor when going at a good clip and meet it perfectly without the character hovering a little above the floor. Pressing a debugging key that dynamically turns on the gravity while the object is hovering has the object fall into that tiny space and meet the floor perfectly. :S
#4
12/26/2012 (8:14 pm)
Are you having issues with direction of force? That can be gotten by doing a dot product IIRC. If you are hand crafting the physics you might look at verlet math.
#5
This isn't technically the right forum to discuss this in but...
It is stopping the character from touching the wall yes but sliding it up to the floor it is not. Manually offsetting the object by the exact proper amount when colliding works but sometimes jiggles the object a little when moving from slope to floor. I've looked all over the past forums for clamp fixing but couldn't find anything.
Wikipedia stinks at explaining technical things to newbies but I think I kind of understand what verlet math is now. That's definitely something to look into.
12/26/2012 (9:18 pm)
One of my problems is that the "clamp" collision response is not clamping.This isn't technically the right forum to discuss this in but...
It is stopping the character from touching the wall yes but sliding it up to the floor it is not. Manually offsetting the object by the exact proper amount when colliding works but sometimes jiggles the object a little when moving from slope to floor. I've looked all over the past forums for clamp fixing but couldn't find anything.
Wikipedia stinks at explaining technical things to newbies but I think I kind of understand what verlet math is now. That's definitely something to look into.
Torque Owner Daniel Buckmaster
T3D Steering Committee
But that time spent thinking about the system - on the train, during dinner, between classes, before going to sleep - I find the most valuable because I throw tons of hypothetical situations at my mind-code to see how it might respond. 'What if this situation is presented to it during gameplay? Or that one?' Of course, you can (and should) try to consider all these cases during your on-paper (or preferred other medium) design stage, and not try to keep it all in your head.
And don't be afraid of rewrites. Keeping your source under version control is a good idea, but even so I've had times where the version history is useless - I literally need to rewrite from the ground up.
In your case, with character movement and slopes, it sounds like you'll be running into lots of maths. Take time and get that part right. Don't just code up some formulae and see if they happen to work right, then leave it if they're close enough. Taking the time to learn trigonometry and vector math will pay off, trust me! (I didn't want to make any assumptions about how much math you know. But since you didn't mention it, I was forced to ;).)