So, just wondering.. how many of you guys actually use "proper" techniques? You know, stuff like commenting, writing pseudocode, that sort of thing.
I learned pseudocode back from my first days programming. It seemed pretty useless, more of a newbie-ish thing to train you to program. Now that I'm doing more advanced stuff, I think it looks more like that thing with arithmetic in school where they make you write long additions when using a many digit number. Sure, it's pretty worthless early on, but later, it's just confusing to do so much of it in my head.
IMHO, flowcharts are a waste of time, though. Only once in a while for hugely complex code, but I'd suggest it for people who are new to programming who are doing something above what they're familiar with.
Comments.. now I'd encourage you to toss them in every few lines. It really helps a lot in the future. I occasionally forget to put in comments after coding too fast, but I always go back and write them. Heck, basic 2 word ones will do, even abbreviations. It helps find things in long code and lets you understand it at glance. And color-coding buggy code also helps a lot.
So, am I really the only one doing this, or do other people do it more than me?
Disclaimer: Any sarcasm in my posts will not be mentioned as that would ruin the purpose. It is assumed that the reader is intelligent enough to tell the difference between what is sarcasm and what is not.
I didn't start grouping events until a good while after I started clicking, which not only helps with organization, but is necessary for some systems to work. I still don't comment often-- just when I need to keep track of what a value is (e.g. Value A = whether or not objects has been selected) so that I don't accidentally use the same value twice. And sometimes, when I have a chunk of code that looks complicated, but is really just a huge set of objects coded in a similar way, I leave a comment to tell what it does in short. That way I don't get confused or overwhelmed later.
I honestly don't know how you pseudocode in MMF. O_o I thought MMF was pseudocode. In fact, I'm not even sure what pseudocode really is. >_O I thought it was writing code in words that are easier to understand than full-fledged code.
Oh, and yea. I think flowcharts are a waste of time and brainpower. When I had to make one in Game Dev class, I just slapped one together in MSPaint to make the teacher happy. UTTER waste of time.
Note that you still can't scroll up on 75% zoom. The actions aren't simply fake example copies; they just haven't been changed from the paste yet at the time I got tired and decided to take a screenshot.
That's when you need pseudocode
Disclaimer: Any sarcasm in my posts will not be mentioned as that would ruin the purpose. It is assumed that the reader is intelligent enough to tell the difference between what is sarcasm and what is not.
O_________________O Yeah, that's complex. I would undoubtedly make one error that would throw the whole thing off. Expression editor strings are hard not to ruin.
I used to not comment (KnP) then eventually got into the practice after making something one night (very very late) then not understanding what it did in the morning. I did that quite a bit. Now I have groups of just comments with update logs, ideas, formulas, story, etc.
I do comment but i also use a pieces of text to seperate groups of events that are within the same MMF group.
I never use flowcharts of pseudo code, IMO thats pretty pointless unless you're trying to sell your idea to someone to get them on board for a team project. All in all I would rather be doing something creative than paper work.
Recently, I'm finding it a lot easier to sketch through the code on paper, then put it in a more proper form in a comment. It's easier to cross out a few lines and rewrite them on paper, but messier But on paper, it's much easier to read something like
X/Y + A/B
Edited by Muz
Disclaimer: Any sarcasm in my posts will not be mentioned as that would ruin the purpose. It is assumed that the reader is intelligent enough to tell the difference between what is sarcasm and what is not.
I tend to use event groups unless I'm making a really simple game, myself. As far as comments go, though, I don't use them a lot unless I'm making a tutorial.
It's something like a middle point between real coding and comments. Helps a lot, depending on how complicated the code is, but for really simple games, it just gets in the way
Disclaimer: Any sarcasm in my posts will not be mentioned as that would ruin the purpose. It is assumed that the reader is intelligent enough to tell the difference between what is sarcasm and what is not.
I sometimes use psuedocode when programming some sort of complex engine. As for grouping and commenting, I do that all the time. I even color-code my comments.
Sometimes I like to use fastloops to perform function calls too.
As for 8-line bits of code in the expression editor, I either macro recurring long bits of the code or break it up into separate actions to make it more readable. I did this in the archery physics engine I published here recently, using a "coeff" alterable value to store the value of a complex radical.
Unless I've got a markerboard with a lot of space to work with, I wouldn't make a flowchart. When I do real programming, though, I sometimes make relational flowcharts to clarify IS-A and HAS-A or USES relationships.
Sometimes I comment things, sometimes I don't, but I almost always put at least a few things into groups now.
I used to never comment anything and most the time not group. I regret not commenting my "Elf beatemup movement", because now when I look at the code, I don't understand what's going on. Haven't looked at the code in awhile, but I bet it's still confusing.
Blood of the Ancient One, Seen only as Shadow, Faster than Lightning, Fierce as the Greatest Dragon, Nearly Invisible, Floating in a Dream, Entered through the Demon Door, Destroyer of Evil in a Realm with a Red Sky Scarred, Who could I be ?
I use groups extensively, which helps avoid commenting since commenting in the list editor i've found is frustratingly buggy (e.g. new comments often show up about 3px tall and you have to resize them).
I've found that the more detailed groups you have, the less comments you need and the more structured your code becomes. Sometimes I actually have only 2 lines of code in a whole group by itself. So for instance, Geronimo's player movement uses these groups:
Player Movement
Motion Variables
Left/Right
Gravity
Jump
Move
Initialise Move Safely
Safety Loop
Test and Cap Inertia
Standing on Floor
Obstacle at Top?
Obstacle at Left?
Obstacle at Right?
Animation
Stopped
Walking
Jumping
Falling
Throwing
Hurt
Player Dies
Jump Attack
Throw Stones Attack
Throw Stones - Apply Velocity
As you can imagine, with that many groups, the need to comment code is minimal.
You can also tuck most of the code away, and see how it's working just from the group names. So in the case of the movement part, I can tell just from the group names that:
1. Motion variables are read from the keyboard input (move left/right, jump, etc) and applied to his internal inertia.
2. Move Safety is initialised (in such a way that it can be recycled and used by other objects later without conflict)
3. The safety loop is run to test for collisions and push out.
4. Tests are run to determine if the player is now next to a wall above, below, left or right, and in any of these cases his inertia in that direction is cancelled (so his gravity doesn't keep building up while he's standing on the floor).
And that's it, that's how his movement works. I actually had almost no recollection of how his movement worked before this, since I hadn't touched it in months. But just reading the group headings reminded me of the whole process
So it's worth doing. I usually don't do pseudocode though. I'll only bother with pseudocode for expressions (and then it's more like algebra, hence why I built Expression Editor Plus). Flowcharts I'll use for diagrams of an application (e.g. you press this option, go to that screen, press that option, go to that screen, etc).
Now how long is it till James strides in and shows us how many groups are in Tormishire?
I comment as much as I can, cause I know that if I don't it'll come back and bite me in the ass later.
I also usually write pseudocode when attempting something new, like a new complex system or the ilk.
I'm not that good at flowcharts though, but they are a huge asset, especially if you take a break from the game. A flowchart can be easier to read than trying to interpret the event editor.
It's usually a truth, that the more work spent outside MMF, the easier the workflow inside MMF.
Flowcharts can be AWESOMELY useful, especially with AI... I should really use them more.
Stuckboy
JC Denton: "I know your UNATCO killphrase: Laputan Machine."
Gunther Hermann: "I - am - not - a - machi --"
JC Denton: "Sticks and stones..."
Deleted User
13th February, 2009 at 02:16:35 -
Originally Posted by DeadmanDines I use groups extensively, which helps avoid commenting since commenting in the list editor i've found is frustratingly buggy (e.g. new comments often show up about 3px tall and you have to resize them).
I've found that the more detailed groups you have, the less comments you need and the more structured your code becomes. Sometimes I actually have only 2 lines of code in a whole group by itself. So for instance, Geronimo's player movement uses these groups:
Player Movement
Motion Variables
Left/Right
Gravity
Jump
Move
Initialise Move Safely
Safety Loop
Test and Cap Inertia
Standing on Floor
Obstacle at Top?
Obstacle at Left?
Obstacle at Right?
Animation
Stopped
Walking
Jumping
Falling
Throwing
Hurt
Player Dies
Jump Attack
Throw Stones Attack
Throw Stones - Apply Velocity
As you can imagine, with that many groups, the need to comment code is minimal.
You can also tuck most of the code away, and see how it's working just from the group names. So in the case of the movement part, I can tell just from the group names that:
1. Motion variables are read from the keyboard input (move left/right, jump, etc) and applied to his internal inertia.
2. Move Safety is initialised (in such a way that it can be recycled and used by other objects later without conflict)
3. The safety loop is run to test for collisions and push out.
4. Tests are run to determine if the player is now next to a wall above, below, left or right, and in any of these cases his inertia in that direction is cancelled (so his gravity doesn't keep building up while he's standing on the floor).
And that's it, that's how his movement works. I actually had almost no recollection of how his movement worked before this, since I hadn't touched it in months. But just reading the group headings reminded me of the whole process
So it's worth doing. I usually don't do pseudocode though. I'll only bother with pseudocode for expressions (and then it's more like algebra, hence why I built Expression Editor Plus). Flowcharts I'll use for diagrams of an application (e.g. you press this option, go to that screen, press that option, go to that screen, etc).
Now how long is it till James strides in and shows us how many groups are in Tormishire?
You know, it's funny, but I only started commenting because people were always raving about it. But you know what, when I started commenting, I never finished anything, or became remotely close. I've actually been coding just like you stated here and it works so much nicer, and I usually never comment unless it has something I need to go back to, like inserting variables I haven't fully planned trough, or just temporary debug get this crap to work code. If I were to go back and comment my current project now, it would be a complete waste of time, and would problably take a week or so to do.
Psudocode is good, but unless you fully understand the language your programing in, then you might as well skip it. Flowcharts in my opinion are on the same level as psudocode, it's whichever one you're comfortable with. When I was in school, the logic and design teacher swore by em, thus, that's the system in which he impressed upon us.
Advertisement
Post Reply
I still don't comment often-- just when I need to keep track of what a value is (e.g. Value A = whether or not objects has been selected) so that I don't accidentally use the same value twice. And sometimes, when I have a chunk of code that looks complicated, but is really just a huge set of objects coded in a similar way, I leave a comment to tell what it does in short. That way I don't get confused or overwhelmed later. 
When I had to make one in Game Dev class, I just slapped one together in MSPaint to make the teacher happy. UTTER waste of time.
Edited by OMC
