Development Any remedies for bad code habits?

[BossJamoke]

I've been messing with Game maker quite a bit for over a year now. I've mostly been following videos and...
Does anyone know any tricks or habits to become more self reliant? I feel as though I can't get very far in coding because I'm relying too much on what I saw in the videos, and it stresses me out to see hours of code that i've written out when I barely even remember what it does or how I might be able to edit it.
Maybe I'm looking for a new way to understand GML itself? Are there any strong, stable code styles that are memorable?

Any personal help or referring to videos would be greatly appreciated!

-AJ

 

[Slow Fingers]

Try to redo projects you've made with tutorials, but without the tutorial, go with memory and manual.
Start simple. Can you make efficient, bug-free collisions, movements, switch room, play sounds, define inputs, etc.
Stuff like that. The habit is to break away from tutorials altogether, and the most basic a thing is, the more important it is to master it.

 

[rIKmAN]

Tutorials themselves aren't bad, the problem is that people write the code from them blindly and don't actually learn what the code itself is doing.

Sure they have "written" a platformer from Shauns tutorials, made an RPG from Heartbeasts videos or a farm game from Friendly Cosmonauts tutorials, but the vast majority of them wouldn't be able to answer if you asked them how arrays work, how lists work or even the difference between local/instance/global variables and general scoping because they simply copied the code without knowing what it is actually doing and why.

The number of "...was not set before use" posts on here vouvhes for that, even when the error message is clear as to what the error is they don't know what is causing it because they likely copy/pasted the code and have no idea how it works. Sometimes they get help and then post again about with the same error message but this time with a different variable. They don't even take in the help they got they just get the quick fix and want to rush ahead and that isn't how coding works.

There are no shortcuts to learning and understanding it, you just have to put the time in and learn at your own speed and try and have fun whilst doing so.

If you want to become self-reliant and write your own code then you need to learn the actual fundamentals of programming and understand things such as loops, scope, how different data structures work and how each one is best used for a specific task.

Yes it's not as Hollywood or glamourous as a platformer, RPG or farming sim but what good is that if you don't understand how it works nor fix any bugs because all that happened was a slow, manual copy/paste of code from the videos into the IDE.

Once you have an understanding of the fundamentals of programming you can use that to build anything you like because all code is based on those same fundamentals - the only difference between languages is usually syntax (give or a take a few language specific features) as the core concepts and logic are the same

I've heard good things about the tutorial series that @samspade has released so I would recommend taking a look at that.
I'm not sure which is the best way to watch the playlists as there seems to be one playlist for pre-2.3 and updated playlist for 2.3+ so maybe @samspade could post in here and advise you better on that but here are the links to both playlists:

GMS2 Coding Fundamentals in GML
GMS2 Coding Fundamentals Update

Also work on small little projects to build your knowledge.
Something like Pong that is simple but that you can build everything needed for a game: player input, moving the paddles based on that input, making the ball move, collision between ball and bats, keeping track of score, adding sounds, adding extra animations to spice things up etc.

Then slowly add difficulty to that and build something like Breakout which has a few new things to learn (storing bricks and their states, level layouts, power ups like multiball, effects on the ball and bat, shooting bullets until the power up runs out, saving the game etc) as well as allowing you to reinforce the knowledge you built from the Pong game (player input, moving the bat, moving the ball(s), collisions, score keeping etc).

People just starting to learn get told to make small games all the time and scoff at the idea, but when you think about it these simple games have all the systems needed just like any other game and can actually be more complex than they look - Breakout is a great example of this with all the things you can add to a basic brick breaking game - but all the Hollywood fluff and graphical pizzazz is removed and you're able to focus on the core mechanics and learn how to put the thing together piece by piece learning along the way about all the fundamentals which can then be used in other more compex games....and the cycle continues because as a programmer you never stop learning.

The manual and Google should become your best friends too, between them the answer to any questions you have will likely be answered but try to get into the mindset of understanding what code is doing and why. Make changes to it and see if it changed what you thought it would, play around with it and understand the concept of what is happening when you changed whatever that thing was, then move onto the next thing.

I've written way more than I intended to, but hope that helps.

 

[Roldy]

and it stresses me out to see hours of code that i've written out when I barely even remember what it does or how I might be able to edit it.

I am unclear if you mean

• you followed a tutorial and then later don't remember what it does

or

• you developed your own code and later on don't remember what is it does

Please clarify.


In general, some advice that might help you is to break down the development of the code into steps. Starting with what you are thinking and developing it into executable code.

1. Write down in english what you are doing
2. Translate that into psuedo code
3. Translate that into actual code
4. Test, find bugs, refactor, repeat

Step 1 is actually the most important, at least to begin with. If you can not explain what you want to do in your natural language you will have a VERY tough time explaining it in a language you are unfamiliar with. When you get more familiar with coding in general or a specific language you will be tempted to skip step one. Do not. Maybe skip writing it down, but at least be able to explain to yourself in english what you are about to code.

Step 2 serves two purposes:

1. It gives you a frame work to step through the code in your mind and refine it before actually coding it
2. Additionally this psuedo code will act as comments for you actual code

e.g.

// Calculate the distance between two 2d points
// Function accepts two points A and B
// Subtract A from B
// Calculate the distance
// Return the value

Then translate this into code using the psuedo code as comments for the actual code:

// Calculate the distance between two 2d points
// Function accepts two points A and B
function FindDistance(_aX, _aY, _bX, _bY) {

    // Subtract A from B
    var _tempX = _bX - _aX;
    var _tempY = _bY - _aY;

    // Calculate the distance
    var _distSquared = (_tempX * _tempX) + (_tempY * _tempY);

    // Return the value
    return sqrt(_distSquared);

}

IF you are following tutorials, instead of just copying what they do, read the code until you understand what they are doing. Then re-write it, from memory and understanding. Get in the habit of understanding the problem and solution, holding it in your mind, and then turning that into code.

Step 3: Translate into actual code. Eventually you will get better and better at this as the programming language becomes more and more familiar like a second language.

Step 4: Coding, Testing, Refactoring, Repeat. This is where you want to get to. This is the actual meat of the process, this is development.

You were once separate haploid cells, then became a diploid cell, then a ball of cells, then a fetus, then premature unborn baby, then a baby, then a child, then an adult. Along the way at various points you were broken, half formed, stupid, ignorant and immature; this is normal. You grew, you learned, you matured; This is development.

Your code is the same. You don't just write it out once and it is perfect and fully functioning. It must develop. Get some code in and run it, see how it broken, keep banging on it until it is not broken. Then use it. See how it sucks. Refactor it until it doesn't suck to use. Repeat.

Get this cycle as short and quick a possible.

 

[samspade]

I really agree with what @Roldy said (and also thank you to @rIKmAN for mentioning my tutorials). For me personally, the thing that helped me to go from feeling like I knew a little bit about coding to feeling (more) free to code what I wanted was when I realized that I could think of things in my head and then translate them into code. And by this I don't mean that I reached the point where I was experienced enough that I thought in code or something like that. Instead I mean that I realized that I could think of an idea first and then, through the process Roldy mentioned, turn that idea into code.

This was a milestone for me because it meant I didn't have to know what code to write before I started coding. I could start with thinking (in English, in concepts, etc) and then have a process for turning those thoughts into code (or if I couldn't at least know what to look or ask for help on). I've actually been trying to write a series on this for awhile and failing.

That said, the more you know how to 'speak' in a language, and speak in the general concepts of programming, the better you are at forming complex ideas out of that language's building blocks. Even writing psuedo code requires a basic idea of how code works in general. Using Roldy's example, saying something like: "Function accepts two points A and B" requires you to understand that there is such a thing as a function and that functions are things that can accept other things as arguments and do things with those arguments. And of course you have to do this not just for the idea of functions but for all the various programming concepts that exist. And this just takes time. You have to internalize them, which means committing them to long term memory, which means physical changes to your brain over time:

A short-term memory's conversion to a long-term memory requires changes within the brain that protect the memory from interference from competing stimuli or disruption from injury or disease. This time-dependent process, whereby experiences achieve a permanent record in our memory, is called consolidation.

The cellular and molecular portions of memory consolidation typically take place within the first minutes or hours of learning and result in changes to neurons (nerve cells) or sets of neurons. Systems-level consolidation, involving the reorganization of brain networks that handle the processing of individual memories, can then happen on a much slower time frame of days or even years.

And of course this process applies not just to the building blocks of any language (although that is the most helpful when you're starting) but to bigger concepts like programming patterns, programming structure, etc.

So you also just want to keep at it and give yourself time to internalize things. You're probably making more progress than you realize.

 

[Lord KJWilliams]

The truth of the matter is, is that everyone's replies here on this post is TRUE

This is how ALL programming languages work. The problem with GML, is that its not taught like other programming languages from a college text book, its taught from a "monkey see - monkey do", point of view. It looks easy - so it looks easy to do, except for the part
where you hit problems and the program does not work as you think, OR does not compile into a executable. You dont know why its not working because you don't know what your doing.

The problem is that people who create the videos that you are watching KNOW what their doing because they have done it so many times. Your first game is going to look like chicken scratch drawn on piece of paper by a toddler who has no drawing skills, in your case little to no programming skills. So the only way to become better at programming is to practice it. How much practice do you put in, is based on how badly do you WANT it.

I say this to every student at my college who learns how to program in C, that comes to me for advice, fails on the basics of what they are learning. For instance, one of the major corner stone concepts that every programmer in C has to know , is pointers. This is also true for learning C++ which is a derived language from C. If you dont know how to use pointers in C, your going to be SORRY.

GML on the other hand is based, from what I have noticed, is centered around being translatable into ECMAscript ( as it is referred to as on www.w3schools.com ) OR Javascript as it is known by. I had to dump out everything I assumed about GML, everything that I learned incorrectly about GML, once I made that realization about how GML relates to ECMAscript. I started rethinking again what I knew.

I also had to learn the difference between a dynamically typed language language and a static typed langauge. C is a static typed language , GML is a dynamically typed language. There is learning curve that I have experienced with GML, even though I know how
to program in C , that made me stop in my tracks with my game idea, and learn the screw nuts and bolts of GML. First there are no streams.....

off-tangent :
If you think programming GML or C, has hard concepts to understand , then come to my level where I am learning x86 Assembler on my own. If you think solving bugs in a higher level language is a pain, then you haven't tried x86 Assembler.. it is UNFORGIVING. x86 Assembler, the low level language, on a 64-bit CPU on a i9 or i7 computer is the most unforgiving programming language that I have ever tried. When a program crashes - it crashes the computer, and you do not have heads or tails of any clue of what caused the bug in the first place, or where in your code the problem happened. In GML or C, the compiler does tell you where in your code where the problem happened - thats the biggest difference that explains why x86 Assembler is unforgiving.

 

[Yal]

My recipe for "learn by doing" goes like this

1. Copy code blindly from somewhere (e.g. steal the Mario 1 source code and put it into your game)
2. Modify it to make it "your own" by changing the few things you can guess how they work (e.g. make goombas move up and down instead of left/right)
3. Repeat a few times and eventually ship the game
4. When making your next project, make it from the pieces you figured out how they worked in steps 2 and 3. Try to glue them together in new ways.
5. If you're CLOSE to being able to do something, but miss a little special sauce, try randomly reading the manual and see if there happens to be functions that let you do that particular thing.
6. Repeat steps 4 and 5 until you know everything.