The Daily Click ::. Forums ::. General Chat ::. "Proper" coding
 

Post Reply  Post Oekaki 
 

Posted By Message

Eternal Man [EE]

Pitied the FOO

Registered
  18/01/2007
Points
  2955

Game of the Week WinnerHero of TimeLOL SignI am an April Fool
12th February, 2009 at 12:51:30 -

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.

 
Eternal Entertainment's Code'n'Art Man

E_E = All Indie


...actually Ell Endie, but whatever.
Image
Image

ben mercer

Possibly Insane

Registered
  11/07/2004
Points
  2538
13th February, 2009 at 01:27:48 -

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.

 
   

Post Reply



 



Advertisement

Worth A Click